JEP 200: The Modular JDK

[mark.reinhold at oracle.com]

2014/8/27 3:08 -0700, david.lloyd at redhat.com:
> An intra-classloader or intra-module access level akin to package 
> access, as previously described in the initial stages of Jigsaw, is 
> easily understood since this is just another access protection flag in 
> class files and is fairly easily accomplished.  However once you start 
> allowing modules to specify what modules may import from it (by name, 
> presumably), you're now forced to define the scope of the names you're 
> assigning,

Yes, though we already have to define the scope of module names simply
because we're introducing modules.

>            and thereby implicitly increasing the user's need to maintain 
> security and integrity not just within modules, but also between them. 

If you're referring to the restricted-export feature, which allows a
module to export public types to a specific set of named modules, then
yes, the maintainers of those modules will have to think carefully about
security and integrity across module boundaries.  In a new code base I'd
hope and expect this feature to be used little, if at all.  This feature
is critical, however, when modularizing a large legacy code base such as
the JDK, as Alan wrote earlier.

> IMO this in turn will imply (even more strongly than before) a loading 
> level that corresponds to the aggregation of modules within a general 
> namespace, which can manage the loading of modules as well as the 
> assignment of their "friends", similarly to how class loaders (and in 
> the future, I expect, modules) are responsible for the security and 
> integrity of loading the classes and resources that comprise it.
> 
> Am I far off the mark here?

No, I don't think so.

- Mark