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

[Bryan Atsatt]

I didn't specify an enforcement mechanism, but we certainly can. One 
simple solution is for Module to expose ClassLoader:

public class Module {
   public ClassLoader getClassLoader() {...};
   public boolean hasModuleAccess(Module m) {...}
}

(I was offline while writing the proposal, and hadn't had a chance to 
read your minutes--sorry for any confusion)

// Bryan


Alex Buckley wrote:
> Thanks for sketching the Module comparison logic I mentioned in the 
> minutes. I don't see how a Module is restricted to one ClassLoader. A 
> module system could pass the same Module object M to 
> CL1.defineClass(..., M) and CL2.defineClass(..., M). What am I missing?
>
> Alex
>
> Bryan Atsatt wrote:
>> 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();
>>    }
>> }
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> jsr294-modularity-eg mailing list
>> jsr294-modularity-eg at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>