Discussion: #MutableConfigurations

[mark.reinhold at oracle.com]

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.

- Mark


[1] http://openjdk.java.net/projects/jigsaw/spec/issues/#NonHierarchicalLayers