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

[Peter Kriens]

Brian,
Your approach makes modules and visibility a module system aspect, it  
is no longer defined in the language.
I therefore feel this is the wrong direction.

In this phase we should only design things that have a well defined  
meaning in the language. Membership and visibility are clearly in that  
domain. The easy cop-out in a design by committee is to make it  
optional or opaque it, means you no longer have to fight about it and  
it looks like we all agree. However, it wreaks havoc for our customers  
and the whole idea of a Java component market.

The fact that we will end up with two module systems is already bad. I  
would like 294 not to fall victim to this fragmentation.

Kind regards,

	Peter Kriens

On 5 mrt 2009, at 23:39, 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090306/8ef88589/attachment.html>