Re: Revisiting JDK-8161269
On 16/09/2016 08:36, David M. Lloyd wrote: OK. For this issue though, would it not make sense to look at the null parent class loader case in a specific and separate way: in the past, such class loaders had access to all platform classes, so as a compatibility factor it would not be unreasonable to take "null" in this *specific* context to mean "platform class loader" and do this translation inside the constructor? Since the change that is really occurring (in any real, observable sense) is that the "null" parent is suddenly shrinking with respect to what it was going back far into history, then the _compatible_ change would appear to be to provide a new ClassLoader value that indicates "java.base (and optionally a few more modules that can decrease over time)", which in reality maps to the bootstrap class loader. This way compatibility is maintained, and the new (in the observable sense) functionality of having a more limited parent CL is still available. Fair point, these constructors could be changed to translate null to the platform class loader. That would need examination from a compatibility point of view too (esp. getParent). It would also create anomalies with other APIs where null is translated to the system class loader. However, I agree it's wroth exploring. -Alan
Re: Revisiting JDK-8161269
On 09/16/2016 10:30 AM, Alan Bateman wrote: On 16/09/2016 07:21, David M. Lloyd wrote: 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). The context here is de-privileging non-core components so that they are no longer defined to the boot loader with all permissions. Modules such as java.corba, java.xml.ws, java.sql and many more have no business or need to be defined to the boot loader. It would be nice, if over the very long term, that we could get to the point where the only module defined to the boot loader is java.base. I don't know if we will ever get there. We of course acknowledge that there is potential compatibility impact with this change and this is why it is called out in the Risks and Assumption section of JEP 261 [1] as "Some Java SE types have been de-privileged and are now loaded by the platform class loader rather than the bootstrap class loader, as noted above. Existing custom class loaders that delegate directly to the bootstrap class loader might not work correctly; they should be updated to delegate to the platform class loader, which is easily available via the new ClassLoader::getPlatformClassLoader method." So far then there hasn't been a lot of feedback on this. The default loader for delegation is the system class loader so someone creating a class loader that delegates to the boot loader is probably an advanced case. As noted in the bug report, the ClassLoader javadoc has been updated for Java SE 9 to define the built-in class loaders. The most important part of this is specifying that all platform classes are visible via the platform class loader. That works for Java SE 8 and older if you replace "platform" with "extension". I mention this in case there is concerns about using a new API in code that needs to be compiled for JDK 8 and run on 8 or 9. I don't have cycles just now to get into the topic of radically changing the class loader hierarchy or how modules on the module path are mapped to loaders - that topic is an order of magnitude larger than the above, esp. once you get into all the scenarios around migration. OK. For this issue though, would it not make sense to look at the null parent class loader case in a specific and separate way: in the past, such class loaders had access to all platform classes, so as a compatibility factor it would not be unreasonable to take "null" in this *specific* context to mean "platform class loader" and do this translation inside the constructor? Since the change that is really occurring (in any real, observable sense) is that the "null" parent is suddenly shrinking with respect to what it was going back far into history, then the _compatible_ change would appear to be to provide a new ClassLoader value that indicates "java.base (and optionally a few more modules that can decrease over time)", which in reality maps to the bootstrap class loader. This way compatibility is maintained, and the new (in the observable sense) functionality of having a more limited parent CL is still available. WDYT? -- - DML
Re: Revisiting JDK-8161269
On 16/09/2016 07:21, David M. Lloyd wrote: 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). The context here is de-privileging non-core components so that they are no longer defined to the boot loader with all permissions. Modules such as java.corba, java.xml.ws, java.sql and many more have no business or need to be defined to the boot loader. It would be nice, if over the very long term, that we could get to the point where the only module defined to the boot loader is java.base. I don't know if we will ever get there. We of course acknowledge that there is potential compatibility impact with this change and this is why it is called out in the Risks and Assumption section of JEP 261 [1] as "Some Java SE types have been de-privileged and are now loaded by the platform class loader rather than the bootstrap class loader, as noted above. Existing custom class loaders that delegate directly to the bootstrap class loader might not work correctly; they should be updated to delegate to the platform class loader, which is easily available via the new ClassLoader::getPlatformClassLoader method." So far then there hasn't been a lot of feedback on this. The default loader for delegation is the system class loader so someone creating a class loader that delegates to the boot loader is probably an advanced case. As noted in the bug report, the ClassLoader javadoc has been updated for Java SE 9 to define the built-in class loaders. The most important part of this is specifying that all platform classes are visible via the platform class loader. That works for Java SE 8 and older if you replace "platform" with "extension". I mention this in case there is concerns about using a new API in code that needs to be compiled for JDK 8 and run on 8 or 9. I don't have cycles just now to get into the topic of radically changing the class loader hierarchy or how modules on the module path are mapped to loaders - that topic is an order of magnitude larger than the above, esp. once you get into all the scenarios around migration. -Alan [1] http://openjdk.java.net/jeps/261
Revisiting JDK-8161269
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
