2014/8/27 3:08 -0700, [email protected]: > 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
