[jsr294-modularity-eg] Proposal: extending module private access
Bryan Atsatt
bryan.atsatt at oracle.com
Tue Mar 10 02:56:11 EDT 2009
Richard S. Hall wrote:
> 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?
In general, yes, I think that is a natural assumption. Clearly fragments
or 'local' modules are exceptions, but these adhere to the "implied
visibility" model I suggest below, so are relatively easy to explain.
>
>> 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?
Isn't Bundle-ClassPath only required when there are nested jars?
Regardless, your point is taken, and maybe the wording is too strong.
(However, this does seems like an implementation detail, and one that
could easily have been handled by convention rather than configuration,
but that's just whining ;^)
>
> -> 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
>>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/1487e3f1/attachment.html>
More information about the jsr294-modularity-eg
mailing list