#VersionsInModuleNames [was: Re: Draft JPMS Public Review specification]

[Neil Bartlett (Paremus)]

I believe the restriction on #VersionsInModuleNames should not be implemented.

In OSGi it is a common practice – though by no means universal – for the bundle identity to be derived from the name of the “top level” package it contains. I expect this will be a common practice under JPMS as well. Therefore the set of allowed module names should be the same as the set of allowed package names. On the other hand if it is logical to disallow versions in module names then they should likewise be disallowed in package names for all the same reasons. Backwards compatibility would require this change to be limited to packages of named modules.

In my experience, when you attempt to take a “best practice” and mandate it universally by technical means, you fail to guarantee good behaviour and you frustrate people who must deal with genuine edge cases. Module authors will still have plenty of opportunities to shoot themselves in the foot, whether or not this particular restriction is enforced. What is really achieved by forcing a module author to write “guava_eighteen” versus “guava_18”… except perhaps confusing non-English speakers?

I would also call the experts’ attention to an email thread on the jigsaw-dev mailing list (http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011657.html <http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011657.html>) and the arguments made by Stephen Colebourne.

Neil


> On 15 Mar 2017, at 13:26, Tim Ellison <Tim_Ellison at uk.ibm.com> wrote:
> 
> "jpms-spec-experts" <jpms-spec-experts-bounces at openjdk.java.net <mailto:jpms-spec-experts-bounces at openjdk.java.net>> wrote on
> 14/03/2017 16:34:23:
>> On 03/14/2017 11:05 AM, mark.reinhold at oracle.com wrote:
>>> 2017/3/12 15:54:41 -0700, tim_ellison at uk.ibm.com:
>>>> ...
>>>> 
>>>> I agree that we should drop the proposal addressing
> #VersionsInModuleNames,
>>>> that module names must end with a Java letter.  Based on
>> practical experience
>>>> there are a number of libraries that have attempted to use a number
>>>> legitimately (i.e. not as a version identifier) and been caught
>> out by this.
>>> 
>>> Examples, please, other than `commons-lang3` and `fabric8`?
>> 
>> You may recall I posted a number of other examples in the email thread
>> about that subject.  But if your answer is always going to be "other
>> than that, what else?" then I guess there's no more discussion possible
>> there.
> 
> My examples are from teams in IBM who have tried adopting early builds,
> and
> hit this as a problem.  While they can work around it by renaming their
> modules
> to something they find unnatural, I find it hard to justify this
> constraint.
> 
>>>> There are any number of bad practices that could be accomplished
> within the
>>>> current design, and attempting to spec them out of existence is
>> quite futile.
>>>> This proposal introduces friction to adoption for a very limited
> gain.
>>> 
>>> If only a couple of projects are affected by this constraint then
>> perhaps the
>>> gain outweighs the friction.
>>> 
>>> Otherwise, is there some other way to discourage developers from
> encoding
>>> version numbers in module names?
>> 
>> I think the point is that AFAICT nobody else agrees that encoding
>> version numbers in module names is a bad practice on its own merits.
>> Whatever it is you are trying to discourage can almost certainly be
>> accomplished in other (substantially worse) ways.
> 
> Indeed.
> 
> Regards,
> Tim
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU