Unnamed module and duplicate package

[David M. Lloyd]

On 3/12/16 9:57 AM, Alan Bateman wrote:
>
> On 11/03/2016 15:30, David M. Lloyd wrote:
>>
>> What are the limiting factors?  In my analysis the only problem that
>> seemed close to insurmountable was the special natives that are used
>> in the JDK but these only seem to be used from java.base.  Does it all
>> boil down to getClassLoader()==null security checks on the Java side,
>> or is there a JVM component that I haven't discovered?
> I have no doubt that it would be a big effort.
>
> One of the most difficult issues when de-privileging is identifying the
> minimum permissions. It gets complicated in areas with callbacks where
> intermediate frames reduce the effective permissions. For several of
> these modules then it may be that they end up needing AllPermission so
> the benefits of moving them out are significantly reduced.
>
> Related is performance when running with a security manager. A long
> standing optimization is that code in the boot loader has AllPermission.
>
> At things stand then we can't move any modules that export java.* APIs.
> If getPlatformClassLoader() and the related spec change to allow java.*
> classes be loaded by the platform class loader and its ancestors goes in
> then it removes this hurdle.
>
> I'm sure there will be lots of other issues once you get into it. Some
> of the modules (like java.management) are tightly coupled to the VM. On
> getClassLoader() returning null then such uses would need to be
> examined. I don't expect there are too many as we replaced a lot of them
> in the JDK 8 time frame as part of JEP 162.

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

2. Come up with a replacement for getClassLoader() == null checks (e.g. 
getClassLoader() == null || getClassLoader().isPrivileged())

3. Then go back and incrementally deprivilege as many modules as 
possible/practical, as time permits

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).

As far as allowing other class loaders to load java.* classes - could it 
not just be a matter of setting a flag on ClassLoader which is only 
settable by a non-public constructor or something like that?  The flag 
could be checked easily by Java or native code, and it doesn't tie the 
JDK more tightly to specific hierarchical class loading arrangements.

-- 
- DML