Usability issue with changes to bootstrap ClassLoader
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Thu Apr 27 20:01:09 UTC 2017
2017/4/12 12:30:57 -0700, Scott Stark <sstark at redhat.com>:
> The current java.lang.ClassLoader api has changed the effective behavior of
> passing in a null value as the parent ClassLoader. When this was raised as a
> regression in bug
> JDK-8161269(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8161269),
> that issue was closed as it had never been specified that all Java SE types
> be visible via the boot ClassLoader.
For context, this change is a consequence of the fact that some classes
formerly loaded by the bootstrap loader are now loaded by the platform loader
in order to improve security. Classes loaded by the bootstrap loader are
implicitly granted all security permissions (`AllPermission`), but many of them
do not actually require all permissions. We "de-privileged" these classes,
i.e., reduced the set of permissions granted to them at run time, by defining
them to the platform loader rather than the bootstrap loader, and by granting
them the permissions they actually need in the default security policy file.
> We would suggest that a less disruptive change would be to document that a
> passing in a null value as a parent ClassLoader would instal the new Platform
> ClassLoader as the parent. This is the effective behavior in all previous
> releases of Java.
This change would not be compatible either, since then the expression `new
ClassLoader(null)` would return a class loader whose `getParent` method would
no longer return `null`. Existing code that expects the parent of such a class
loader to be the bootstrap class loader could break.
Neither change is clearly better than the other. The original change has been
in the prototype RI for about two years now, and we've had very few reports of
difficulties arising from it. The workaround is straightforward, as noted in
8161269 -- you simply replace
new ClassLoader(null)
with
new ClassLoader(ClassLoader.getPlatformClassLoader());
On balance, I think it's less risky to retain the original change.
- Mark
More information about the jpms-spec-comments
mailing list