David M. Lloyd
david.lloyd at redhat.com
Mon Jan 30 14:26:20 UTC 2017
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:
>>> 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  to state
>>> that a module name appearing anywhere in a source-form module
>>> declaration must both start and end with "Java letters" .
>> 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 , the first being
> `commons-lang3` .
The difference, from my perspective, is that Fabric8 is an important Red
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
>> 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
>  http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000393.html
>  http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-September/009366.html
More information about the jpms-spec-observers