Proposal: #VersionedDependences

[Robert Scholte]

On Mon, 30 Jan 2017 15:26:20 +0100, David M. Lloyd  
<david.lloyd at redhat.com> wrote:

> On 01/26/2017 04:35 PM, mark.reinhold at oracle.com wrote:
>> 2016/12/9 14:10:43 -0800, david.lloyd at redhat.com:
>>> On 12/09/2016 03:46 PM, mark.reinhold at oracle.com wrote:
>>>> ...
>>>>
>>>> Proposal
>>>> --------
>>>>
>>>> ...
>>>>
>>>> Now that compile-time versions can be recorded in module descriptors
>>>> there is even less need to tolerate version information in module  
>>>> names,
>>>> a bad practice that we'd like to discourage at the outset.  We  
>>>> therefore
>>>> further propose to:
>>>>
>>>>  - Revise the accepted proposal for #VersionsInModuleNames [3] to  
>>>> state
>>>>    that a module name appearing anywhere in a source-form module
>>>>    declaration must both start and end with "Java letters" [4].
>>>
>>> Can we just drop this part?  I really am not a fan of the
>>> social-enforcement-in-technical-code thing, and I can already think of
>>> one existing project off the top of my head that will suffer
>>> collaterally from this: Fabric8.  Also any other project to which the
>>> "vanity license plate effect" would apply.
>>
>> This is only the second example that's been pointed out since I posted
>> the original proposal for #VersionsInModuleNames [1], the first being
>> `commons-lang3` [2].
>
> The difference, from my perspective, is that Fabric8 is an important Red  
> Hat project.
>
> Also to be subsequently annoyed, from 5 minutes of searching just on  
> GitHub: "CS###", "Excercise###", "Lab###", "Chapter###"; fx2048 (i.e.  
> number based games); Simple8583 (ISO-8583 framework); projects relating  
> to the (apparently several) devices out there whose name ends in a digit  
> or several digits; things referencing JSR numbers like  
> jackson-datatype-jsr310; things ending in a year (relating to events  
> like conferences and that sort of thing); things relating to versions of  
> a certification or specification (like our jta-1_1 API projects and  
> similar), etc.
>

As far as I know there has never been a restriction or a specification  
regarding the usage of numbers in the filename. And even if there would be  
such a specification, it won't apply anymore on the current world or jars  
(if desired, I could try to get these statistics from Central). Assuming  
it is always a version and that the base followed by those numbers are  
always part of the same base-artifact is simply not correct.

>>>                                             And I can think of many  
>>> ways
>>> to circumvent this rule, including, but not limited to, bracketing with
>>> letters "v5slot", roman numerals, etc., so really all it does is add an
>>> annoying "big brother" effect without practical benefit.
>>
>> Sure, you can work around it, but disallowing the obvious abuses should
>> go a long way towards encouraging people to do the right thing.
>>
>> If this restriction really becomes a problem then we could consider
>> loosening it in a later release.  If we lift it now and this kind of
>> abuse becomes common then we'll have no way to go back.
>
> If this "abuse" is common, then... so what?  I think the error here is  
> assuming there is a globally "right" thing to do, when it's already  
> clear that there are valid and useful cases where this is not true, and  
> I'm telling you now from a place of experience that having multiple  
> versions of a thing is not by itself any kind of anti-pattern.  Like  
> anything in software, it can be abused, but taking away an obvious  
> feature in order to ensure that users behave in one certain way has  
> always been a regrettable mistake in my experience.  Especially when the  
> primary problem o
>
> I think that users are going to be far more annoyed by the restriction  
> than benefited by it.
>
>>> Anyway I disagree pretty strongly that versions (or more specifically,
>>> version segments) in module names are that really that strong of an
>>> anti-pattern.  Sure having whole version numbers in is a pretty fragile
>>> technique, but it's very useful to have (for example) multiple major
>>> versions of a library on a large distribution to ease migration,
>>> especially when you're talking hundreds or thousands of modules.
>>
>> In the context of JPMS, I respectfully disagree.  We long ago chose
>> explicitly not to solve the version-selection problem in this module
>> system, leaving it to build tools and container applications.
>
> Yes however what this policy implies is not "we will not solve this  
> problem" but "we will not only not solve this problem, we will make many  
> reasonable solutions impossible".  People are still going to do this;  
> their solutions are just going to be weirder and the resultant problems  
> harder to solve.  The basis for any agreement on our part with this  
> requirement was that, while we don't have explicit support for "multiple  
> versions" (which has been repeatedly shown to be a very hard-to-define  
> expression, by the way), we will do nothing to prevent it either.
>
>>  If we
>> allow digits at the end of module names then we just invite confusion.
>> "I wrote `requires foo4` but I have `foo5.jar` on my module path, why
>> doesn't that work?"
>
> The obvious answer is because foo4 is not the same as foo5, and  
> experience tells me that users historically have been able to figure  
> this out without any problems.
>

This is what happened at Devoxx BE, when somebody from the audience  
suddenly had trouble to compile his Java9 project with Maven, while it  
used to work before. The root cause was actually the upgrade from Java9,  
which changed this versioned dependences behavior.
He had a line like ' requires jsomething2;'. When I told him he should  
remove the '2' he could confirm that it works, however the next valid  
question was "but how can I make the difference between the old jsomething  
and this jsomething2"? Well, that's not possible anymore.

Robert

>> - Mark
>>
>>
>> [1]  
>> http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000393.html
>> [2]  
>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009366.html
>>