Discussion: #MutableConfigurations

[David M. Lloyd]

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.

>
> 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).
>
>         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]).
>
>             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