Dynamic modules and bidirectional interoperation

[mark.reinhold at oracle.com]

2016/10/28 10:01:17 -0700, Remi Forax <forax at univ-mlv.fr>:
>> De: mark.reinhold at oracle.com
>> Envoyé: Vendredi 28 Octobre 2016 18:16:49
>> 2016/10/28 8:41:41 -0700, Remi Forax <forax at univ-mlv.fr>:
>>> De: mark.reinhold at oracle.com
>>> Envoyé: Mercredi 26 Octobre 2016 19:24:47
>>>> ...
>>>> 
>>>> Yes, the parents of a new configuration will be specified in an ordered
>>>> list and during resolution they'll be searched depth-first, in the order
>>>> in which they occur in the list.  Depth-first order makes it easy to
>>>> reason about resolution, since it works just like a search path.
>>> 
>>> I fail to seen how this is not a mini-classpath with exactly the same
>>> issues as the classpath.
>> 
>> It's not a "mini" class path; it's more like a "mini" or "run time"
>> module path.  It's better than a class path because it's a means to
>> locate whole modules rather than individual types, as discussed in
>> SotMS:
>> 
>> http://openjdk.java.net/projects/jigsaw/spec/sotms/#the-module-path
> 
> it's not a modulepath it's a moduletreepath, so i agree it does not
> have exactly same issue as the classpath, but the main issue is very
> similar, if you take a look to the list of parents, it's not enough to
> see which module will be chosen, like with the classpath, if you open
> all the jars you will find your cookie, with the moduletreepath, if
> you crawle the tree in deep-first order, you will find your module, in
> my opinion, in both cases, if you take a look to the list of jars or
> the list of parents, you have no idea where to find what you're
> looking for.

Ah, now I think I see what you're getting at, which is a completely
different issue.

Yes, it's true that all of the parents, direct and indirect, of a new
configuration are logically arranged in a tree rather than a linear
path, owing to the depth-first search.  This is a behavior shared with
the class path (cf. the `Class-Path` attribute in `MANIFEST.MF`).

As long as we specify it clearly then I'm not convinced that the
complexity is a serious problem, since only a few experts are likely
ever to use this API.

>              And here, it's even worst, because at least the classpath
> has a string representation.

Why is that interesting?  These lists of parent configurations (and any
related lists of layers) will only ever be specified programmatically.
We're not proposing this for use on the command line, or in system
properties, or in any other context that needs a string representation.

- Mark