ClassLoader initialization in _Jv_RunMain
Mon Nov 10 05:26:00 GMT 2003
>>>>> "Bryce" == Bryce McKinlay <email@example.com> writes:
Bryce> The ClassLoader static initializer runs a whole lot of code, and we
Bryce> are running it before (eg) we have attached to the main thread, which
Bryce> is problematic. Removing it doesn't seem to have had any negative
Bryce> effect -
Bryce> presumably ClassLoader would be the only place that refers to
Bryce> VMClassLoader anyway, so VMClassLoader should never get initialized
Bryce> first. Can we remove this?
We can't, since we can get into circular initialization problems. As
I remember it, the problem I saw was that initializing
gnu.gcj.runtime.VMClassLoader caused ClassLoader to be initialized,
and so forth, but then we'd call into VMClassLoader to load a class,
causing us to reference ClassLoader.systemClassLoader, which hadn't
been set, leading to spurious failures.
I only saw this with a complex example, according to my notes it was
eclipse. Setting up a precompiled eclipse to test this isn't easy
:-(. I should have written a small test case, shame on me.
I agree, though, that we shouldn't do this until the first thread is up.
Perhaps we can change how systemClassLoader is set to solve the
I'll back out this patch tonight and build a new eclipse. Tomorrow
I'll try it out and report back.
More information about the Java