Proposal: #VersionedDependences

forax at forax at
Fri Jan 27 18:19:09 UTC 2017

Hi Ali, 

> De: "Ali Ebrahimi" <ali.ebrahimi1781 at>
> À: "jpms-spec-observers" <jpms-spec-observers at>, "mark reinhold"
> <mark.reinhold at>
> Cc: "Remi Forax" <forax at>
> Envoyé: Vendredi 27 Janvier 2017 17:52:01
> Objet: Re: Proposal: #VersionedDependences

> Hi,

> On Fri, Jan 27, 2017 at 2:06 AM, < mark.reinhold at > wrote:

>> 2016/12/15 9:20:51 -0800, forax at :
>> > 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/at
>> > - 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.

> Why we don't add source code support for version string in module declaration?
> module foo at 1.0{
> ....
> }

> module bar at 2.0{
> ....
> }

> This way when code reviewing we know what is version of module.
> Also, we don't have Remi's mentioned problem of multi-module code bases.

when you do things like security patch by example, you may update several module versions but want only to commit the change corresponding to the security fix, 
i.e. not having the security fix hidden in the middle of a lot of module-info useless updates. 
In my opinion, it's close to inserting the source control version inside a code, it's an anti-pattern. 

> --

> Best Regards,
> Ali Ebrahimi


More information about the jpms-spec-observers mailing list