[jsr294-modularity-eg] Proposal: extending module private access
bryan.atsatt at oracle.com
Fri Mar 20 15:09:35 EDT 2009
(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
> 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?
> - It must be possible for member types of a runtime module to be
> defined by different classloaders.
> - 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
>> 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
>>>> 15. It must be possible for two or more modules to share types
>>> I think that unless we discover unexpected consequences of those two
>>> requirements, they both sound very reasonable.
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer