Proposal: #VersionedDependences

[David M. Lloyd]

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.

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

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

-- 
- DML