RE: ServiceFactory

[David Holmes]

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