Proposal: #VersionedDependences

forax at univ-mlv.fr forax at univ-mlv.fr
Sat Jan 28 12:36:06 UTC 2017


----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: forax at univ-mlv.fr
> Cc: jpms-spec-experts at openjdk.java.net
> Envoyé: Vendredi 27 Janvier 2017 23:24:21
> Objet: Re: Proposal: #VersionedDependences

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

Ok !
so for the record, in my opinion, versioned requires should have been encoded in a separated non JPMS attribute, but it's too late to change the classfile format and we have to move on.

> 
> - Mark

Rémi


More information about the jpms-spec-observers mailing list