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

[Alex Buckley]

(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.

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.

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