Proposal: #VersionedDependences

[mark.reinhold at oracle.com]

2017/1/27 9:53:23 -0800, forax at univ-mlv.fr:
> 2017/1/26 14:36:31 -0800, mark.reinhold at oracle.com:
>> 2016/12/15 9:20:51 -0800, forax at univ-mlv.fr:
>>> ...
>>> 
>>> 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.
> 
> yes, but given that a version is a string, you should be able to store
> anything in it, if the value is not inserted by javac but by jar.

A version is not just a string, and we should not encourage people to
use versions to encode information that's not a version.

>> ...
>> 
>> 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.
> 
> It's something we have swept under the rug, but the version (of the
> module or of requires) format should not be Java specific.

It should be as general as possible but it should be well-specified.
In that sense it will be Java-specific.

> I see no problem to have the ModuleBuilder to enforce a specific
> format but a ModuleDescriptor should return an Optional<String> (it
> can also retruns an Optional<Version> in an overloaded method but it
> should be possible to get the string version).
> 
> Version format depends on the module system, it should be enforced by
> the code that creates the Layer.

Yes, the version format depends on the module system, and that module
system is JPMS.  We're not designing multiple different module systems,
nor a low-level framework upon which multiple different module systems
can be implemented.  The JPMS version format attempts to encompass a
wide variety of existing version schemes, but it does not (and can not)
encompass them all.

>>> 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.
> 
> it's compelling for those debugging a large system and not having an
> artifact repository ...  being able to get the sources (+
> configuration) for something you have shipped is all what you need.

... if you have an artifact repository.

>>> - 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.
> 
> Compiling several times will not play well with incremental
> compilation, if you change a module B required by another module A
> that do not change, having to re-compile module A that have not
> changed just because you have to update the version of the requires
> directive in A is a very bad property of a build process.

The mention of a `--module-version` compiler option in the proposal
is only a suggestion; it will not be a normative part of the JPMS
specification.  If complex multi-module, multi-version, incremental
compilation scenarios become a real problem then compiler implementors
are free to do something fancier.  I don't think we need to spend any
more time on this point.

- Mark