Discussion: #MutableConfigurations

[Remi Forax]

I may say something stupid but if you have one Layer by ClassLoader, why it's not enough ? 

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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.