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.
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.
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.
4. TCCL.
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.
