This is the mail archive of the
mailing list for the Mauve project.
Re: ClassLoader.findLoadedClass (was: ServiceFactory)
- From: "Robert Lougher" <robert_lougher at hotmail dot com>
- To: brawer at dandelis dot ch, dholmes at dltech dot com dot au, chris at kiffer dot eunet dot be, aph at redhat dot com
- Cc: classpath at gnu dot org, mauve-discuss at sources dot redhat dot com
- Date: Mon, 22 Mar 2004 13:15:39 +0000
- Subject: Re: ClassLoader.findLoadedClass (was: ServiceFactory)
Interesting -- that's a documentation change between 1.3 and 1.4. In the
specs for 1.3 it simply says:
protected final Class findLoadedClass(String name)
"Finds the class with the given name if it had been previously loaded
through this class loader."
Which is suitably vague enough for several interpretations. Pragmatically,
a class loader must keep track of the classes defined by itself so it
doesn't try to define them again. This appears to be
However, as Sascha points out, 1.4's explicitly says it should return
classes _recorded by the virtual machine_ as initiated by the loader.
Strictly, this doesn't mean all classes initiated by the loader, just the
ones recorded by the VM. As I said, if loadClass is called implicitly by
the VM it's recorded as an initiating loader, but not if loadClass is called
explicitly by the programmer. The JDK is therefore correct, as loadClass
was called explicitly.
In fact, nowhere in the documentation does it say that calling loadClass on
a class loader makes it an initiating loader of the returned class!
The bad news is that Classpath (at least 0.07) is wrong according to the new
documentation. It won't handle classes recorded by the VM as being
initiated by it. Perhaps it should be moved into the VM class, so that a VM
can do it natively using its internal class tables? (Alternatively, a VM
can implement it as a call back to record it as an initiating loader).
----Original Message Follows----
From: Sascha Brawer <email@example.com>
To: David Holmes <firstname.lastname@example.org>, Chris Gray
<email@example.com>, Andrew Haley <firstname.lastname@example.org>, Robert Lougher
CC: GNU Classpath <email@example.com>, <firstname.lastname@example.org>
Subject: Re: ClassLoader.findLoadedClass (was: ServiceFactory)
Date: Mon, 22 Mar 2004 10:15:54 +0100
Robert Lougher <email@example.com> wrote on Mon, 22 Mar 2004 09:
>However, in the explicit case, the initiator has been lost --
>defineClass only has the defining loader, and we don't have an "add
>initiating loader" call for use when we unwind. Even if findLoadedClass
>native so it could use the VM class cache, the VM wouldn't know that,
>your example, L1 initiated the load and would return null.
Does this mean that the API specification for ClassLoader.findLoadedClass
is incorrect? Or should it say that a VM may or may not record the fact that
some ClassLoader has initiated the loading of a class?
> protected final Class findLoadedClass(String?name)
> Returns the class with the given name if this loader has been recorded
> by the Java virtual machine as an initiating loader of a class with
> that name. Otherwise null is returned.
Sascha Brawer, firstname.lastname@example.org, http://www.dandelis.ch/people/brawer/
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo