[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ClassLoader.findLoadedClass (was: ServiceFactory)
From: |
Sascha Brawer |
Subject: |
ClassLoader.findLoadedClass (was: ServiceFactory) |
Date: |
Mon, 22 Mar 2004 09:13:59 +0100 |
David Holmes <address@hidden> 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, address@hidden, http://www.dandelis.ch/people/brawer/
TestClass.java
Description: Text document
findLoadedClass.java
Description: Text document
Re: ServiceFactory, Sascha Brawer, 2004/03/22