On 14/03/2016 07:27, David M. Lloyd wrote:
So really there are multiple parts to be able to move modules out of
the bootstrap class loader:
1. Relax the spec so that other class loaders (preferably only
trusted/blessed class loaders) can define java.* classes
This is part of the getPlatformClassLoader() patch that Mandy sent mail
about a few days ago. As part of this, defineClass is relaxed so that it
allows java.* classes to be defined to the platform class loader or any
of its ancestors
2. Come up with a replacement for getClassLoader() == null checks
(e.g. getClassLoader() == null || getClassLoader().isPrivileged())
jdk.internal.VM.isSystemDomainLoader(ClassLoader) was introduced in JDK
8 for this purpose.
3. Then go back and incrementally deprivilege as many modules as
possible/practical, as time permits
Easier said that done as it can take a lot of effort to identify the
minimum permissions, test, measure performance, assess compatibility and
the many other things that need to be done.
However the benefits seem attractive: improved security (even if only
one module gets deprivileged), ability for core modules to depend on
upgradable modules (java.sql case).
Yes, on security although some modules need to granted more permissions
that we'd like. So far, we've moved all of the EE/upgradeable modules:
java.activation
java.annotations.common
java.corba
java.transaction
java.xml.bind
java.xml.ws
and several service provider (jdk.*) modules have been moved too.
I don't see core modules depending on upgradeable modules as a benefit.
My personal view is that we should vehemently resist any move in that
direction. No issue with core modules using service providers of course.
-Alan
