Some suggested patches and improvements

[David M. Lloyd]

On 05/16/2017 06:02 AM, Alan Bateman wrote:
> On 12/05/2017 14:31, David M. Lloyd wrote:
> 
>> :
>>
>>> There is a lot more to #5, something that will become clear when you 
>>> work through all the scenarios. The JSR and spec part are minor 
>>> though but I'd prefer to hold off until there is more discussion on 
>>> this topic in the JSR.
>>
>> I'd rather not hold off as the JSR essentially only has a couple of 
>> weeks left to live if there is not a revised PR.  Could you please 
>> explain what you mean?  Are you referring to jlink, jaotc, or 
>> something else?
>>
> For the most part, this is not a JSR issue.  In any case, some of the 
> issues from other exploration and prototypes in this area:
> 
> 1. Interaction with code on class path, esp. when you have two or more 
> modules in the configuration for the boot layer that export the same 
> package.

I would say that isolated modules should be inaccessible from the class 
path, and can be specified accordingly.  I don't think this would cause 
any particular usability concern or surprise; isolated modules are 
specifically intended to solve problems like package duplication that 
already means that the class path can't sensibly interact with them in 
an direct way.

Also, if a user is going so far as to isolate modules from one another, 
I think it's a relatively small step to modularize whatever class path 
code they have.

> 2. Split delegation issues that can arise when explicit modules on the 
> module path do qualified exports to upgraded modules or even tool or 
> automatic modules defined to the application class loader.

I'll have a look at the upgraded modules code; I didn't realize that 
they would work differently from a normal module path module.

Automatic modules should be subject to the same behavior as regular 
modules, but I'll double-check that as well.

By tool modules, are you referring to jdk.compiler etc.?

> 3. Visibility of types in non-exported packages, say where you have 
> jdk.compiler defined to its own class loader but have code on the class 
> path that makes use of types in conjunction with encapsulation busting 
> options.

The current patch only allows application modules to be isolated. 
Otherwise this seems to be related to #1: I think it's reasonable to 
prevent class path code from accessing isolated modules.

I think it's important to note that the class path does not need to have 
direct access to the full set of modular features - especially if such 
access would come at the cost of truncating that feature set.

> 4. TCCL.

For this one I was thinking that TCCL should be set to the class loader 
of the module that was executed.  In the non-isolated case, this would 
be the application class loader, but in the isolated case it would 
depend on whether or not the main module was isolated.

> There are other issues that arise from changing visibility but these are 
> no different to issues that arise when using graphs of class loaders.
> 
> -Alan.
> 


-- 
- DML