Proposal: #VersionedDependences

[forax at univ-mlv.fr]

Hi Mark,

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Jeudi 26 Janvier 2017 23:36:31
> Objet: Re: Proposal: #VersionedDependences

> 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.

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.

> 
>> 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.

Java already use non standard attributes for things specific to Java ...

> 
>> 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.

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

> 
>> 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.

> 
>>  - 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.

I was pretty happy with a world without a version on requires, specifying the version using the command jar which make a lot of sense because it's when you bundle everything together (code + resources), when you create the module. 

> 
> - Mark

Rémi