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
