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

[Peter Kriens]

Sorry for the delay, been on the road too much lately.

I understand that (now) that you want to allow runtime access through  
a Module method. This would allow a module system to define the  
membership as it sees fit. I agree, I had understood that this would  
be needed at compile time as well, which I think is not a good idea, I  
really think the compiler should not require the module system. If it  
does, I do not see how we can escape defining this module system.  
Which is not feasible in the given time frame.

So it seems we agree on this issue! :-)

Kind regards,

	Peter Kriens



On 6 mrt 2009, at 21:00, Bryan Atsatt wrote:
> 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
>>
> _______________________________________________
> 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