[jsr294-modularity-eg] Proposal: extending module private access
Bryan Atsatt
bryan.atsatt at oracle.com
Mon Mar 9 19:27:58 EDT 2009
After giving this issue more thought, it seems to me that 1) the
requirement is misstated, and 2) there is another requirement. :^)
Revised requirement:
It must be possible for two or more modules to share types privately.
The original version assumed a solution, but clearly should not (and yes
using the term 'share' in the requirement may not be explicit enough,
but is probably ok for now). I think what we are all after here is a
mechanism by which multiple modules can cooperate using types that are
not available to "outsiders". We can choose to define 'available' as
either visible or accessible; my assumption is that we would prefer the
latter, as it is a stronger guarantee.
This requirement might then be thought of as "group access". And we
should probably consider whether satisfying this requirement is worth
creating an entirely new mode, with new access flags, etc. So far,
however, we've discussed solutions that:
1. Restrict visibility (permits/"friends")
2. Extend module private access to others (isAncestor() or
hasModuleAccess())
3. Define "runtime module" such that it can span class loaders (and
hence deployment modules).
My initial reaction to #3 was that it was somehow "wrong", but I
couldn't articulate why. In my proposal, I had a partial answer: it
breaks the intuition that a runtime module is directly related to a
deployment module, the concrete thing that you manipulate
(download/transport/install/start/stop/uninstall). IOW, it violates the
principal of least surprise.
I now think there is another, stronger reason: visibility assumptions.
There exists an *implied visibility within a module*; no explicit
configuration (e.g. import/export) is required to gain visibility to
member types. This is obvious, if unstated, when you consider a single
deployment module. And the principal of least surprise would clearly be
violated if it did not apply across multiple deployment modules in the
same runtime module.
I believe that this is worth elevating to a new requirement:
Member types must share visibility without configuration.
Or, stated in a perhaps less ambiguous way:
Member types must be visible to one another without configuration.
So... Before we define a solution, can we please try to reach agreement
on these two requirements?
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.
// Bryan
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090309/8a46b6bf/attachment.html>
More information about the jsr294-modularity-eg
mailing list