This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: null ClassLoader
- From: Tom Tromey <tromey at redhat dot com>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: Torsten R|ger <torsten dot rueger at firsthop dot com>, java at gcc dot gnu dot org
- Date: 19 Dec 2001 17:36:38 -0700
- Subject: Re: null ClassLoader
- References: <Pine.LNX.4.10.10111280033000.9325-100000@mars.deadcafe.org>
- Reply-to: tromey at redhat dot com
>>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:
I'm finally looking at this again.
Jeff> We could propose that libgcj.so is special and all other
Jeff> (user-)compiled classes have a non-null loader. Perhaps we
Jeff> would add a flag to jc1 for building libgcj.so with the
Jeff> bootstrap (null) loader, and a compiled-in instance of a
Jeff> singleton loader that would be used for all subsequent calls to
Jeff> _Jv_RegisterClasses (since the loader is really defined when the
Jeff> class is registered).
This all sounds pretty ugly.
How important is it that the class loader for, say, java.lang.Object
be different from the class loader for org.user.Whatever?
One simple fix would be to simply always set the loader field when
registering a class. The reality is that all classes in shared
libraries which are linked into the application *are* loaded by our
"bootstrap" loader.
Equivalently, we could change Class.getClassLoader so it only returns
`null' for primitive classes.
Tom