Discussion: #MutableConfigurations

[David M. Lloyd]

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 Layer (or even more than one Layer, if you want).
>
> 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.
>
>>                                                                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]).
>
>>             If 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.

-- 
- DML