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

[Bryan Atsatt]

Peter, sorry, but your response is quite puzzling to me: I am seeking a 
simple model that enables the more complex one you propose (and 
simultaneously addresses BJ's layering requirement).

First, I think you are confusing "access" with visibility; my proposal 
says nothing about visibility, only access.

Second, Alex's spec defines "runtime module" as "the pair of its module 
name and defining classloader". I think we have agreed that "runtime 
module" can be defined instead by the association of a Module object to 
each Class during defineClass(). Unless I misunderstand, this is 
precisely what your proposal relies on, as does mine.

Your proposal requires the VM to defer part of the access check to 
Module.isAncestor(). Mine simply generalizes this concept.

Your proposal extends module private access to all "child" modules, but 
does not provide a way for siblings to share. BJ's extends this to any 
deployment module that has it's Classes labeled with the same Module 
instance, regardless of ClassLoader, but introduces a significant 
disconnect between the meaning of a deployment and a runtime module.

My proposal seeks to rectify both shortcomings, while retaining the 
benefits.

// Bryan


Peter Kriens wrote:
> 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 
>>> <mailto: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 
>> <mailto: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/c5c20dd6/attachment.html>