Multiple class loaders problem

Anthony Green green@redhat.com
Sun Nov 3 16:51:00 GMT 2002


I believe this test case points out a bug in our ClassLoader implementation.
It requires a dummy bytecode class "dummy.class"....
---- cut here ------------------------------------
import java.net.*;
public class TestMultiple
{
 class MyLoader extends URLClassLoader
 {
 public MyLoader (URL urls[])
 {
 super (urls);
 }
 }
 public static void main (String[] args)
 {
 URLClassLoader ucl = 
 (URLClassLoader) ClassLoader.getSystemClassLoader();
 URL urls[] = ucl.getURLs ();
 MyLoader t1 = new MyLoader (urls);
 MyLoader t2 = new MyLoader (urls);
 Class c1, c2;
 try {
 c1 = t1.loadClass ("dummy");
 c2 = t2.loadClass ("dummy");
 } 
 catch (Exception e) {
	e.printStackTrace ();
 }
 }
}
---- cut here ------------------------------------
This produces a LinkageError, with the message "class dummy already
loaded". My understanding is that it shouldn't, because dummy is being
loaded into different ClassLoaders. Sun's implementation doesn't fail
here.
I'm not certain, but I believe the problem is in ClassLoader.loadClass.
If the class isn't loaded, and the parent class loader can't load it,
then it calls gnu.gcj.runtime.VMClassLoader.instance.findClass(). 
However, for normal classes (.class files), this will always pass. The
dummy class will be associated with our VMClassLoader instead of the
MyLoader instance, and the second load will fail.
Sun's ClassLoader.loadClass documentation says "Call the loadClass
method on the parent class loader. If the parent is null the class
loader built-in to the virtual machine is used, instead." We would need
the built-in loader to fail for this test case to work. Is our
VMClassLoader doing the wrong thing?
AG


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /