[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 22 Mar 2004 09:03:12 +0000
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.
----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
> > 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
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.
Classpath mailing list
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo
Re: ServiceFactory, Sascha Brawer, 2004/03/22
Robert Lougher <=
- Re: ServiceFactory, (continued)