Configurations... (Was: Re: Module-system requirements)

[David M. Lloyd]

On 02/14/2015 03:33 PM, mark.reinhold at oracle.com wrote:
> 2015/2/12 7:35 -0800, david.lloyd at redhat.com:
>> I'm a little concerned that the configurations section implies a strict
>> hierarchy:
>>
>> "Nested dynamic configurations — An application must be able to create a
>> dynamic configuration that relates to an existing dynamic configuration
>> rather than to the application’s initial configuration."
>>
>> Why can a configuration not relate to more than one other configurations?
>
> A tree of configurations rather than a simple linear list is more
> difficult to reason about and trickier to implement (you must, e.g.,
> cope with the diamond-import problem).
>
> The feedback we've received so far has not suggested that this
> limitation will be a problem in practice.  Do you have use cases
> which require this flexibility?

We implement not just a tree, but a general directed graph (even 
allowing cycles) among modules and among their configurations (module 
loaders), which enables us to easily support OSGi and Java EE, as well 
as tying these things to filesystem JARs (e.g. for EE deployments which 
have Class-Path declarations that have an absolute path name), and the 
legacy extensions mechanism which is presently also a part of Java EE 
(though this is going/has gone away, I understand), and also allows 
tying in other systems as well.

Due to the way we support imports, diamonds are really no problem.  Each 
module's dependency list is interpreted in order, so the set of imported 
resources is always the union of everything exported by each dependency. 
  So if you acquire a different set of items via two different "paths" 
to a module, you get the union of those sets in the end.  Duplicated 
paths are removed such that the first occurrence is used.

-- 
- DML