Revisiting JDK-8161269

David M. Lloyd david.lloyd at
Fri Sep 16 14:21:06 UTC 2016

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.




More information about the jigsaw-dev mailing list