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

[Alex Buckley]

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