Unnamed module and duplicate package

[Alan Bateman]

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.

-Alan