class loader

[Jeff Sturm]

On 2 Apr 2001, Tom Tromey wrote:
> The argument is: `null' is correct as far as the docs go, but some
> real programs rely on the return value never being null.  Apparently
> neither the Sun nor IBM JDKs ever return null, so in effect we would
> be making this change in the name of bug compatibility.

Not true.  Try the following on any version of the JDK:

System.out.println(Class.forName("java.lang.Object").getClassLoader());

A `null' classloader has always been interpreted as the "system"
classloader.  In 1.1 and earlier the system classloader loaded all
classes unless the user code installed a custom classloader.  In 1.2
Sun implemented a classloader to handle the user's classpath, while
the system classloader is still used for core JDK classes.  (I don't know
exactly why they did, but it has the nice benefit that the java.* core
classes can no longer be overridden with CLASSPATH, producing unexpected
results.)

> Ordinarily I'm in favor of correctness on the part of everybody.  But
> in this situation the change would leave libgcj correct, while
> enabling more programs to work.  Is anybody opposed to this change?

What change?  (Did I miss a patch?)

Give that two classes are equal if and only if they have the same name and
share a classloader, the only reasonable thing to do IMO is always return
the same instance for compiled classes, or just `null' as it stands now.
Whichever you choose it'll be a little different than Sun's JDK, but then
they don't have compiled classes to deal with, so that's not so strange.

FWIW I'd vote `null' for compiled classes, and an explicit classloader
for interpreted classes (which is exactly what we have now).

Jeff