Discussion: #MutableConfigurations

[Neil Bartlett (Paremus)]

> On 13 Jul 2016, at 21:27, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> On 07/13/2016 03:09 PM, Remi Forax wrote:
>> I may say something stupid but if you have one Layer by ClassLoader, why
>> it's not enough ?
> 
> Even if you have one layer per classloader per module, you can add modules but you cannot update them when they are removed.

Speaking from an OSGi perspective (though NOT as an official representative of OSGI)… if we map the current OSGi bundle concept to a JPMS Layer then this has a few important consequences:

1. Bundle dependencies are not hierarchical but form a directed graph. I see there is a separate proposal for non-hierarchical layers, but I haven’t determined yet whether it is sufficient to achieve this mapping.

2. The dependency graph may contain cycles. Cycles are just as undesirable in OSGi as they are in JPMS, but the fact is they are supported so to forbid them now would be an incompatible change.

3. Bundles that have no dependers (i.e. they are leaf nodes) can easily be updated or uninstalled. But non-leaf bundles can cause effects on all the bundles that depend on them. This is handled by a resolving process that requires all bundles involved in it to be stopped, re-resolved (i.e. have their imports matched with corresponding exports) and then restarted. “Stopping” and “starting” mean invoking callback methods within the bundle so that they can clean up any instances that might refer to the obsolete types, e.g. threads. Thus a modifiable graph is intrinsically tied to the full lifecycle provided by OSGi. I find it difficult to imagine how JPMS could safely provide limited lifecycle facilities (add/update/remove) without replicating the full OSGI lifecycle or something like it.

4. If bundles are mapped to Layers then it seems likely that each Layer will consist of just a single Module, since we have no need for intra-bundle isolation other than that already provided by packages and types.

5. If Layers are arranged in an inter-dependent graph, and each contains a solitary Module, then a Layer looks very much like the thing we should be calling a “module”, and the Modules as currently defined by JPMS are redundant!

6. OSGi’s dynamic abilities are enabled by a dynamic Service Registry. If a bundle providing a service is removed then all consumers of that service are notified so that they can release references to it. There is no corresponding facility in the ServiceLoader API. This is not a problem for OSGi users since we will continue using our own Service Registry, but how can JPMS safely support removal of a Layer/Module if it provides services that have been retrieved by another Layer/Module?


I tend to believe these issues are insurmountable, or would require more change to the JPMS spec than the EG is prepared to make. I expect therefore that OSGi will not be able to map bundles to JPMS modules. Instead our bundles would exist within the context of a single JPMS module (perhaps unnamed). This is a shame because OSGi will not be able to take advantage of the additional access-based isolation offered by JPMS, and must continue relying on its visibility-based isolation… on the other hand we at least avoid JPMS’s problems with #ReflectiveAccessToNonExportedTypes. My current work is on enabling some degree of interoperability so that bundles can declare dependencies on JPMS modules in the platform, which would be understood and honoured by the OSGi Framework.



> 
>> 
>> Remi
>> 
>> 
>> On July 13, 2016 6:42:56 PM GMT+02:00, "David M. Lloyd"
>> <david.lloyd at redhat.com> wrote:
>> 
>>    On 07/13/2016 09:30 AM, mark.reinhold at oracle.com wrote:
>> 
>>        Reference:
>>        http://openjdk.java.net/projects/jigsaw/spec/issues/#MutableConfigurations
>> 
>>        2016/3/2 18:11:34 -0800, david.lloyd at redhat.com:
>> 
>>            It appears from what I can see in the Jigsaw code, that once a
>>            Configuration is calculated, it cannot be changed in any way,
>> 
>> 
>>        That's true.
>> 
>>        The overall model in the present design is that, given a set of
>>        modules,
>>        you first compute a configuration, which captures the resolution
>>        of all
>>        the modules' dependences in a consistent fashion. You then
>>        instantiate
>>        that as a Lay! er (or even more than one Layer, if you want).
>> 

Switching to addressing an earlier comment by Mark:

>>        This model is motivated by one of our primary goals, namely reliable
>>        configuration. Resolving a complete configuration, rather than doing
>>        so incrementally, allows the early detection of missing, duplicate,
>>        and conflicting dependencies.


The ability to modify a configuration after it has been created does not imply that it must be created incrementally, or that it is “unreliable".

When launching an OSGi application we start with a number of bundles. These bundles are resolved together, allowing "early detection of missing, duplicate and conflicting dependencies” (though OSGi is more forgiving about duplicates and conflicts). At a later time, a subset of bundles can be updated or uninstalled, or new bundles added. These operations are batched and we can determine ahead of time whether a batch would succeed or would leave some bundles in an unresolved state. I’d like to know in what way this process can be characterised as unreliable.




>> 
>>            which
>>            makes them unsuitable for use in containers which add and
>>            remove modules
>>            at run time. It is not clear how such containers are expected to
>>            function.
>> 
>> 
>>        They're expected to create Layers, which can be related
>>        hierarchically as
>>        needed (or perhaps more generally, cf. #NonHierarchicalLayers [1]).
>> 
>>            I! f there is a deliberate intention that the Jigsaw system
>>            will not support dynamic modification of layers/configurations
>>            (including the dynamic addition and removal of modules at
>>            run time),
>>            then that should be explicitly stated.
>> 
>> 
>>        I don't think it makes sense for Configurations to be mutable,
>>        for the
>>        reasons stated above. It may be that the Layer concept needs to
>>        be made
>>        more dynamic in certain ways, but that's a different matter.
>> 
>>        I intend to close this issue unless there are strong objections from
>>        other EG members.
>> 
>> 
>>    In that case, other EG members take note: this means that hot deployment
>>    as the world knows it is over as of Java EE 9, since a module can never
>>    delete old or establish new dependence relationships.  This also means
>>    that OSGi loses this capability as well, so either OSGi has to be
>>    redefined with the new restriction, or else OSGi bundles cannot be modules!
>>      .
>> 
>> 
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 
> --
> - DML


Neil Bartlett