Proposal: #VersionedDependences

[mark.reinhold at oracle.com]

2016/12/15 9:20:51 -0800, forax at univ-mlv.fr:
> I do not like this proposal for several (good) reasons.

(Well, of course they're good reasons!)

> The issue asks to be able to store a version strings or a constraints.
> It can be interpreted as two different things.
>  - the configuration used by example by Maven which uses constraints
> that will be resolved,
>  - the other is the effectively resolved versions which is what this
> proposal do.
> In my opinion, storing the former info maybe more interesting for a
> language (the actual configuration) than storing the later.

Storing version constraints might be more interesting, but we can't
do that in JPMS since JPMS (intentionally) does not have a concept of
version constraints.

> We already agree that we support annotations (and obviously classfile
> attributes) so any languages are free to store this kind of information
> in it's own annotation/attribute, which is more flexible.

Well sure, but the question here is what, if anything, we should do for
Java itself.

> If we still want to store the version of each requires, i think it's
> better to store it in a side attribute (an array of versions should be
> enough) than in the Module attribute, it's more aligned with the way we
> encode ModuleVersion currently.

The proposal exposes recorded version strings in the standard API, via
a new method in the `ModuleDescriptor.Requires` class:

    Optional<ModuleDescriptor.Version> compiledVersion();

These strings are no less standard than any of the other information
exposed in the standard `ModuleDescriptor` API, so recording them in
the main `Module` attribute seems perfectly appropriate.

> The flag --module-version in javac is useless:
>  - it's an optional feature that few will use, so runtimes can not use
> it reliably, so it's as useful as -parameters,

I don't think we can reliably predict, today, how many people will or
will not use this feature.  In the abstract it is compelling, especially
to those of us with experience debugging large systems built from many
components, so at this point I'm inclined to keep it.

>  - you often need to compile several modules together, if a module A
> requires a module B and the module B uses a service from module A, but
> --module-version can only specify one version for all the modules
> compiled together.

The expectation is that if you're compiling a set of modules together
then they're all related, and hence likely all have the same version
string.  The workaround is to invoke the compiler more than once.  If
this really becomes a problem then a compiler could accept a more complex
flag that specifies a map of module names to version strings, but that
seems like overkill at this stage.

- Mark