Re: ServiceFactory

[Chris Gray]

On Friday 19 March 2004 15:32, Sascha Brawer wrote:
> Chris Gray <address@hidden> 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                                  address@hidden             
            +32 477 599 703