David Holmes <dholmes@dltech.com.au> wrote on Mon, 22 Mar 2004 09:22:43 +1000:

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.

Please find attached a testcase for Mauve (put the two files into gnu/
testlet/java/lang/ClassLoader).

My understanding of the API spec [1] is that on line 51 of the testlet,
the result of calling findLoadedClass should be 'klass' because 'loader'
is an initiating loader for "gnu.testlet.java.lang.ClassLoader.TestClass". 

[1] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/
ClassLoader.html#findLoadedClass(java.lang.String)

On JDK 1.4.1_01, the testlet fails because the result returns null. Same
for JamVM, which is based on Classpath.

If people agree that both the JDK and the Classpath-based VMs are buggy,
I'd commit the test case into Mauve and file bug reports with Classpath
and Sun.

-- Sascha

Sascha Brawer, brawer@dandelis.ch, http://www.dandelis.ch/people/brawer/