[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ServiceFactory

From: Robert Lougher
Subject: RE: ServiceFactory
Date: 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 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

Express yourself with cool new emoticons

reply via email to

[Prev in Thread] Current Thread [Next in Thread]