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

[Bryan Atsatt]

Bryan Atsatt wrote:
> (Sorry, I need to fix my address book; this is the second time I've 
> made that same mistake.)
>
> Alex Buckley wrote:
>> (Somehow discussion moved to the private EG list, which doesn't seem 
>> necessary, so I'm moving it back to the mirrored list.)
>>
>> Bryan Atsatt wrote:
>>> For Monday, can we (pretty-please :^) step back from the solution 
>>> discussion(s) and see if we can agree on some variant of these 
>>> requirements?
>>
>> Yes.
>>
>> As you stated earlier, we want multiple modules to cooperate using 
>> types that are not available to "outsiders".
>>
>> Do we agree that "not available" means "not accessible", i.e. the 
>> JVM's accessibility rules distinguish between a member of a module 
>> and a non-member of a module ? I believe we do.
I certainly think we should start with that, and only fall back to "not 
visible" if we can't find a reasonable solution.
>>
>> When we think in terms of accessibility, the rule can be simple: 
>> "Access to a module-private type/member succeeds if the requesting 
>> type has the same runtime module as the requested type/member." A 
>> class's runtime module is the Module object passed to defineClass, 
>> and possibly more.
Yes, this was my earlier point, where we can consider some wiggle room 
in the definition of "same" in "same runtime module".
>>
>> May I then summarize requirements in terms of runtime modules?
>>
>> BJ:
>> - It must be possible for member types of a runtime module to be 
>> defined by different classloaders.
>>
>> Bryan:
>> - Member types of a runtime module must be visible to one another 
>> without configuration.
>> - It must be possible for two or more runtime modules to share types 
>> privately.
>>
>> Alex
>>
>>> Michal Cierniak wrote:
>>>> On Mon, Mar 9, 2009 at 3:54 PM, Bryan Atsatt 
>>>> <bryan.atsatt at oracle.com> wrote:
>>>>  
>>>>>    14. Member types must be visible to one another without 
>>>>> configuration.
>>>>>    15. It must be possible for two or more modules to share types 
>>>>> privately.
>>>>>     
>>>>
>>>> I think that unless we discover unexpected consequences of those two
>>>> requirements, they both sound very reasonable.
>>>>
>>>> Michal
>>>>
>>>>
>> _______________________________________________
>> 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