This is the mail archive of the
mailing list for the Java project.
Re: PR 12001 - ClassLoader fix
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:
I was afraid you were going to say that
We can't do this, because it is an incompatible (relative to Sun) API