Discussion: #MutableConfigurations

[mark.reinhold at oracle.com]

2016/7/13 9:42:56 -0700, david.lloyd at redhat.com:
> On 07/13/2016 09:30 AM, mark.reinhold at oracle.com wrote:
>> ...
>> 
>> 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.

First, neither OSGi nor any other existing module system will lose any
capability at all.  They can continue to operate just as they do today.
We already have a requirement [1] to support interoperation with such
systems, and so far as I can see it's satisfied by the present design.

Going further to design a "meta" module system that allows other module
systems to be retrofitted to interoperate on an intimate basis with the
platform module system is, as I've written before, a research project
that's clearly outside the scope of this JSR [2].

Second, it's certainly true that the present design does not support
fully-general "hot deployment" in which arbitrary modules can come and go
and be reconfigured at any time.  That's intentional, because doing so
would entail enormous complexity and make it incredibly difficult, if not
impossible, to achieve the stated goals of this JSR.  That's also why the
agreed requirements mandate not this general capability but, rather, a
more constrained dynamic-configuration capability, which the present
design addresses with the concept of layers.

- Mark


[1] http://openjdk.java.net/projects/jigsaw/spec/reqs/#interoperation
[2] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2015-February/000019.html