Re: PR 12001 - ClassLoader fix

[Nathan Bryant <nbryant at optonline dot net>]

Tom - thanks for taking a look. the rationale is that the patch makes 
the system classloader available in that static variable (which is 
needed by Class.forName() during the Calendar initialization) before it 
has all the url handlers for the classpath elements added, but this 
period of time is limited to the time when the classloader itself is 
initializing the url handlers, and we should only be loading compiled-in 
system classes during this period anyway

potential consequence - if somebody tries to override native-compiled 
system classes with the CLASSPATH variable, well with this patch now 
they can't override the ones that are loaded during that period of URL 
handler initialization. but i think that was mostly the case already 
before the patch because a lot of our linking is handled by ld instead 
of traditional java classloader semantics. I think the answer is "don't 
do that," anyway.

I'm fuzzy/confused about how your proposed split native/gij-emulated 
classloader would look. Seems like it might mean that system classes 
wouldn't be able to load emulated classes, if the emulated classloader 
is the child?

Tom Tromey wrote:

> We can't do this, because it is an incompatible (relative to Sun) API
> change.
I was afraid you were going to say that