null ClassLoader

[Jeff Sturm]

On 26 Nov 2001, Tom Tromey wrote:
> Couldn't we just return the same class loader for bootstrap classes as
> well as user-defined classes?  I don't think any of our code relies on
> the class loader being null.  So we might as well make this change,
> just to make things convenient for those who assume that class loaders
> are never null.  Is there any reason not to make the change?

I don't think it will work for all classes.  Suppose we change libgcj.jar
so java.lang.Object appears to have been loaded by e.g. a SharedLibLoader.
But the superclass of SharedLibLoader is ClassLoader, and the super of
that is java.lang.Object.  So java.lang.Object must be loaded before any
SharedLibLoader can be instantiated, and thus a SharedLibLoader cannot
have loaded java.lang.Object (or java.lang.ClassLoader for that matter).
That is the paradox.

We could propose that libgcj.so is special and all other (user-)compiled
classes have a non-null loader.  Perhaps we would add a flag to jc1 for
building libgcj.so with the bootstrap (null) loader, and a compiled-in
instance of a singleton loader that would be used for all subsequent
calls to _Jv_RegisterClasses (since the loader is really defined when the
class is registered).

That seems straightforward, if not simple... or do I misunderstand the
problem?

Jeff