Hi Alan,

In JDK-8161269 you said [1] that the "null" class loader has never been specified to contain all Java SE types, using this as a justification to reject this issue as "Not an Issue", regardless of the compatibility impact (particularly the common case of a class loader with a null parent).

However in a recent email [2] on the topic of letting module path modules each reside in a separate class loader so as to allow for duplicate non-exported packages, you seem to imply that the impact of changing the class loader of a library, even one on the module path, is a compatibility risk though there were no concrete details given.

What is the standard for compatibility? I contend that there are real frameworks today that are in wide usage that have assumed that a null class loader contains all platform classes; however, I have yet to run across any framework that worked under a class path (i.e. application class loader) but failed as soon as it was loaded under its own isolated class loader (in our case, as a module under JBoss Modules). By my empirical experience, the former is a significant compatibility risk, while the latter is not; by the standard you have set in these two places, it appears that the former is not a risk (or not enough of one to warrant action) but the latter would be, so I was hoping you'd expand a bit so I can get a better understanding of where you're coming from.


[1] https://bugs.openjdk.java.net/browse/JDK-8161269?focusedCommentId=13973088#comment-13973088 [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009255.html


Reply via email to