Re: ClassLoader.findLoadedClass (was: ServiceFactory)

["Robert Lougher" <robert_lougher@hotmail.com>]

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 
Classpaths'interpretation.

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).

Rob.

----Original Message Follows----
From: Sascha Brawer <brawer@dandelis.ch>
To: David Holmes <dholmes@dltech.com.au>, Chris Gray 
<chris@kiffer.eunet.be>, Andrew Haley <aph@redhat.com>, Robert Lougher 
<robert_lougher@hotmail.com>
CC: GNU Classpath <classpath@gnu.org>, <mauve-discuss@sources.redhat.com>
Subject: Re: ClassLoader.findLoadedClass (was: ServiceFactory)
Date: Mon, 22 Mar 2004 10:15:54 +0100

Robert Lougher <robert_lougher@hotmail.com> wrote on Mon, 22 Mar 2004 09:
03:12 +0000:

 >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 
was
 >native so it could use the VM class cache, the VM wouldn't know that, 
using
 >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.

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/
ClassLoader.html#findLoadedClass(java.lang.String)

-- Sascha

Sascha Brawer, brawer@dandelis.ch, http://www.dandelis.ch/people/brawer/

_________________________________________________________________
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo