Discussion: #NonHierarchicalLayers

[mark.reinhold at oracle.com]

Reference: http://openjdk.java.net/projects/jigsaw/spec/issues/#NonHierarchicalLayers

2016/3/2 16:07:06 -0800, david.lloyd at redhat.com:
> If there is any expectation of moving existing systems over to Jigsaw, I 
> think that the strict hierarchical layer system should be abandoned in 
> favor of a graph-oriented system.  This allows containers to maintain 
> separate module graphs with separate namespaces which nevertheless 
> interconnect.

I suspect that generalizing the design to allow non-hierarchical layers
is possible, but tricky.  Both configurations and layers would be able to
have multiple parents, so the API would become more complex, but perhaps
that's okay since this is more for expert than casual use.  To avoid
having to deal with conflicts between parents (i.e., the diamond-import
problem), it'd likely be best to make the collections of parents be lists
rather than sets, so that they're searched in a determined order.

> I believe that this is a necessary requirement if (in particular) there 
> is an expectation that Java EE 9 (or another Java EE specification) 
> would be reframed in terms of Jigsaw-style modules, since Java EE module 
> names have many fewer restrictions, and it is possible for (for example) 
> more than one application to contain modules of the same name.

I don't understand how these two observations motivate non-hierarchical
layers, but maybe I'm missing something.

Module names are an entirely distinct issue [1].  The constraints on
module names could be relaxed regardless of whether or not layers are
hierarchical.

It's already possible to have multiple modules of the same name with
simple hierarchical layers.  Two hosted applications can contain a module
of the same name as long as they're loaded into distinct, unrelated
layers.  (Even two layers that are related can contain modules of the
same name, in which case the resolver chooses the module in the nearest
layer.)

Are there other reasons why a hypothetical future Java EE specification,
which allows applications to be built from collections of JPMS modules,
might necessitate non-hierarchical layers?

> If on the other hand there is an expectation that Java EE is not going 
> to be retrofitted in a way which maps EE applications and modules to 
> Jigsaw modules, then this should be clearly declared.

As I wrote earlier, we definitely do have that expectation -- that's why
the requirements include an entire section on dynamic configuration.

- Mark


[1] http://openjdk.java.net/projects/jigsaw/spec/issues/#ModuleNameCharacters