[Bug classpath/22714] SystemClassLoader ignores java.class.path property for classfiles

[gcc-bugzilla at gcc dot gnu dot org]

It appears that while gnu.java.lang.SystemClassLoader is
written with the intent to use the "java.class.path" system
property as its search path for classfiles, in fact this
doesn't work.

The reason is that the "java.class.path" logic is implemented
via SystemClassLoader.findResource(), but this method is
not invoked by the superclass (java.lang.ClassLoader) when
searching for class files.

Instead, the call trace goes like this:

ClassLoader.loadClass() ->
ClassLoader.findClass() ->
throw new ClassNotFoundException()

Now, this of course only happens when the parent class
loader (in this case the JVM boot loader) is unable to
load the class. But this is a perfectly valid case.

Often times, the "bootstrap" class path (which is
used by the JVM boot loader, but is entirely separate
from the application class path specified by the
"java.class.path" system property) contains the class
file being searched for, which masks this bug, but not
always.

To witness this bug, try setting your boot class path
to NOT contain ".". Then set the "java.class.path"
system property to contain ".". Now try to run a class
from the command line that is in the current working
directory (in some random directory).

This will work with e.g. Sun's JDK but not with a
Classpath based JVM.

The fix is for SystemClassLoader to override the
findClass() method. The Classpath javadoc for
ClassLoader.findClass() gives sample code for
doing so.


------- Comment #1 from from-classpath at savannah dot gnu dot org  2004-01-05 
02:07 -------
Oops, the patch has a small bug.
The last line should read:

  return defineClass(name.replace('.', '/'), buf, 0, buf.length);


------- Comment #2 from from-classpath at savannah dot gnu dot org  2005-02-06 
00:24 -------
This is now fixed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22714