In JDK-8161269 you said  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  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.
- Revisiting JDK-8161269 David M. Lloyd