Discussion: #MutableConfigurations

[David M. Lloyd]

On 07/19/2016 04:10 PM, mark.reinhold at oracle.com wrote:
> 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.

I would like this to be true, but unfortunately, operating as we do 
today is not going to be a long-term option for us given 
previously-discussed future requirements relating to Java EE 9 (see below).

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

I disagree that it's "clearly" out of scope; what you've delineated as 
"research project" versus design parameters seems arbitrary to me.  It's 
certainly been made to be out of scope for the current implementation 
but it could have easily been a part of the design to begin with.

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

We cannot support this restriction.  Our Java EE container is built on 
the ability to support hot deployment; this pronouncement, in 
combination with the earlier pronouncement that Java EE 9 will almost 
certainly require deployment units to be modules, is an unacceptable 
result for us.  There must be some way for us to achieve this, either by 
adding the necessary flexibility to configurations or by allowing 
another way to define and redefine modules outside of the constraints of 
the current implementation.

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

I completely disagree.  Class files, as defined since the very start of 
Java, meet the exact same goals for classes as are stated in the JPMS 
requirements for modules, and they do so by using an incremental 
algorithm that allows for classes to be loaded and unloaded at any time. 
  Our (JBoss) module system does the exact same thing, in a very similar 
way, for the same reasons, and still manages to provide the same 
requirements (sans accessibility restrictions, which can only be part of 
the VM, but which could be accomplished using techniques I've previously 
proposed).  It's clearly possible to do.

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

The problem is that with layers being strictly hierarchical and 
configurations immutable, it will not be possible for us to deliver a 
Java EE 9 compliant server without essentially starting over, and giving 
up important capabilities in the process.  I don't see how we can 
possibly agree to this.  We simply must have some way to reconfigure 
modules at run time, *and* some way to introduce dependence 
relationships with modules from extra-hierarchical layers - in addition 
to resolutions to certain other previously-raised issues - in order to 
move our technology towards Java EE 9, or else we need the guarantee 
that there will be no requirement for Java EE 9 or any future Java EE or 
related specification which involves mapping Java EE applications, 
modules, and/or their constituent pieces directly to named JDK-style 
modules.  I more than anyone want to find a way to make this work but I 
just don't see any way around it.

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

-- 
- DML