[jsr294-modularity-eg] Proposal: extending module private access

[Bryan Atsatt]

Requirement:

14. It must be possible for two or more modules to share module private 
types.


Rationale:

Modules are a relatively fine-grained unit, and module private access as 
originally envisioned is scoped within that unit. However, larger scale 
compositions of modules may have a similar requirement to share types 
within that composition, but prohibit access from classes outside the 
composition.

An existing proposal to address this requirement (Nested Modules) 
introduces the concept of a container, a hierarchical relationship 
between modules within that container, and a model for extending module 
private access to any child module; further, it requires rules for 
merging identically named hierarchies.


Proposal:

The new terminology in VM 5.4.4 Access Control uses the phrase "is a 
member of the same runtime module". This proposal defines "runtime 
module" as an instance of the Module class, and defers the meaning of 
"same" to the Module implementation, decoupling details of the policy 
from the language and VM. Specifically, a public non-final method is 
added to class Module:

public class Module {
    public boolean hasModuleAccess(Module m) {
        return this == m;
    }
}

To perform the access check, the JVM must invoke this method at least 
once for any pair of Module instances, and may cache the result.

Instances of the Module class are created by a module system and passed 
to ClassLoader.defineClass() for association. An accessor method is 
added to java.lang.Class:

public class Class {
     public Module getModule() {...} // Passed in at defineClass().
}

Further, this proposal defines the relationship between Module and 
ClassLoader: a ClassLoader may have many Module instances, but a Module 
may have only one ClassLoader.


Discussion:

This proposal preserves the simple conceptual model in which there is a 
1:1 mapping between:

  1. A deployment module and a runtime module.
  2. A runtime module and a ClassLoader.

while providing a flexible access model for module private types, 
methods and fields.

Given a source class 's'  that is attempting to access target class 't' 
(or its fields or methods), the access check is simply:

      s.getModule().hasModuleAccess(t.getModule())

A module system may override the default ("same module instance") 
policy. For example:

public class HierarchicalModule extends Module {

    public boolean isAncestor(Module m) {...};

    public boolean hasModuleAccess(Module m) {
        return this == m || isAncestor(m);
    }
}

Or:

public class ScopedModule extends Module {

    public Scope getScope{...};

    public boolean hasModuleAccess(Module m) {
        return this == m || getScope() == m.getScope();
    }
}