Configurations... (Was: Re: Module-system requirements)
David M. Lloyd
david.lloyd at redhat.com
Mon Feb 16 14:12:50 UTC 2015
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
>> "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.
More information about the jpms-spec-observers