RE: ServiceFactory

[Robert Lougher]

If you look at Classpath's code, you'll see that findLoadedClass checks the 
loaders cache.  However, a class is only added to it when the class loader 
defines it.  As loadClass (correctly) tries to delegate before trying to 
find the class itself, a class will never be added to this loaders' cache if 
it was loaded by a parent.  This means JamVMs behaviour is correct -- 
findLoadedClass will return null, as C was delegated to, and loaded by L3.

To get the behaviour you expect loadClass would have to add delegated 
classes to the cache as well.  However, I believe Classpath's behaviour is 
correct and not a mistake in Classpath.

There are two ways a class can be loaded by  a class loader.  Explicitly by 
calling loadClass and implicitly by the VM when encountering a symbolic 
class reference that must be resolved -- the VM mustt call loadClass on the 
class loader that defined the current class (unless the VM can tell it's 
already an initiator for that class).  In this case the VM must record the 
loader as an initiating loader, even if the class is defined by somebody 
else.  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.

Rob.

----Original Message Follows----
From: "David Holmes" <address@hidden>
To: "Chris Gray" <address@hidden>, "Sascha Brawer" 
<address@hidden>,"Andrew Haley" <address@hidden>
CC: GNU Classpath <address@hidden>
Subject: RE: ServiceFactory
Date: Mon, 22 Mar 2004 09:22:43 +1000

Chris Gray wrote:
> On Friday 19 March 2004 15:32, Sascha Brawer wrote:
> > I've tried to call ClassLoader.findLoadedClass on the initiating 
loader,
> > but it contrast to what Sun's Javadoc says, it returns null both on the
> > JDK 1.4.1 and on JamVM.
>
> Hm, that's interesting. I would expect Wonka to return the same non-null
> result (C.class) for each of L1, L2, L3 in my example.  If L1 and
> L2 were to return null then the standard loadClass() logic will still
> work(*), but it could make a difference to a user-defined class loader.
>
> (*) If L1 or L2 were asked to load C a second time, then they
> should see in step 1 that they already loaded a class with this
> name. But if findLoadedClass() returns null they will both delegate
> to L3, and presumably L3's findLoadedClass() will return C.class,
> so no harm is done - it's just not what the spec says.

>From what I've read, the specification of findLoadedClass and definition 
of
the class cache in terms of an initiating classloader, are intended to
prevent a malicious classloader from breaking the lookup process. If each
classloader delegates correctly to its parent then there is, as you say, no
harm. However, if the parent does not play nicely then different class
instances could be returned.

This seems like a bug in the JDK implementation of findLoadedClass.

David Holmes



_______________________________________________
Classpath mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/classpath

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