Revisiting JDK-8161269

[David M. Lloyd]

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.

Thanks!

[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

--
- DML