This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:

We can't do this, because it is an incompatible (relative to Sun) API

I was afraid you were going to say that

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]