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 [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
