bootclassloader problem (gcc 4.0 regression)

Thu Apr 14 00:48:00 GMT 2005

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

Per> The problem is:
Per> Class.forName("module1")
Per> is in a compiled class ModuleInfo.java, where "module1" is supposed to
Per> resolve to "./module1.class".
Like Mark said, we talked about this extensively on irc today.
The fundamental problem here is that gcj and more ordinary java
environments have different linking models. In particular, we have a
notion of "linking code into the executable" which is lacking in the
JDK. Andrew and Mark made the convincing argument that users would
expect their --main class to appear to be loaded by the system class
loader.
I "cleaned up" this area while working on the endorsed directories
patch. I didn't think through that this would break applications
doing Class.forName().
In the short term (4.0 branch) I think we can reverse a change in
_Jv_FindClass and have it use the system loader instead. This change
is incorrect, but it probably won't hurt too many real applications in
practice.
In the long term (cvs trunk) I think we should add a new flag to gcj
and then use it to compile libgcj. This flag would emit Class objects
with a special flag so that libgcj can differentiate between the two
kinds of classes linked into the executable: those "loaded" by the
system loader and those loaded by the bootstrap loader. I don't
really like adding another compilation mode like this, but I don't see
another good way to recognize this distinction.
I'm testing the needed patch. Eclipse still works fine with it in
place. I downloaded and built Kawa as you said, and that worked fine
too. I still need to test Jonas before submitting it.
Tom