[jsr294-modularity-eg] Proposal: extending module private access
Richard S. Hall
heavy at sun.com
Mon Mar 9 19:43:22 EDT 2009
On 03/09/2009 07:27 PM, Bryan Atsatt wrote:
> 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.
Are you saying there is a one-to-one mapping between runtime modules and
deployment modules?
> 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.
Wouldn't OSGi be in violation of this then, since it requires a
Bundle-ClassPath to gain visibility to member types?
-> richard
>
> 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
>>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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-observer/attachments/20090309/2ab297a3/attachment-0001.html>
-------------- next part --------------
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
More information about the jsr294-modularity-observer
mailing list