On Friday 19 March 2004 15:32, Sascha Brawer wrote:
> Chris Gray <[EMAIL PROTECTED]> wrote on Fri, 19 Mar 2004 13:59:28 +0100:
> >c.getClassLoader() returns the class loader which defined the class. Since
> >your CustomClassLoader quite properly uses the default loadClass()
> >implementation, Class c may be loaded by an ancestor. So your test needs
> > to match myClassLoader, but also the transitive closure of getParent().
>
> Thanks, Chris. My mistake was that I thought Class.getClassLoader() would
> return the initiating class loader, not the defining class loader. Since
> there does not seem to exist an easy way to find the initiating loader,
> I'll simply omit the two offending tests.
As I read it, if class loaders L1 and L2 are both asked to load class C, and
both delegate to class L3, then C has at least two initiating loaders (L1,
L2) but only one defining loader (L3). So there is no such unique object as
"the initiating loader of C".
> 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.
--
Chris Gray [EMAIL PROTECTED]
+32 477 599 703
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
