This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: null ClassLoader
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Torsten R|ger <torsten dot rueger at firsthop dot com>, java at gcc dot gnu dot org
- Date: Wed, 28 Nov 2001 00:52:52 -0500 (EST)
- Subject: Re: null ClassLoader
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