Unnamed module and duplicate package

[Alan Bateman]

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