Missing issue: Version string format

[David M. Lloyd]

Neil Bartlett also is expressing skepticism that one general syntax can 
be suitable for all or even most module systems, pointing out that a 
general scheme like this not only breaks the "final freeform field" 
aspect of OSGi versions but also the fact that under OSGi, a version of 
e.g. "1.0" is exactly equal to "1.0.0", which *may* be possible to 
achieve in a general system but probably not in combination with 
multiple, sortable separators.

It's feeling more to me like maybe Rémi is right and module versions 
should just be Strings, and furthermore that version validation (via 
Predicate?) and sorting (via Comparator) should be implemented by the 
module layer, with a general scheme (perhaps like this one) being 
available for ease of implementation and a specific scheme (like this 
one plus semantic rules) for the default module layer.  Note (as an 
aside) that this also eliminates the need for the hacky static Version 
cache that is used as a simple deduplication mechanism in 
jdk.internal.module.Builder#cachedVersion, so it already "feels" better 
in at least one other way.

Any thoughts on this?

On 03/21/2016 07:30 PM, Remi Forax wrote:
> Hi David,
> maybe a stupid question but
> given that there is no need for a version of a module in the JDK,
> why do you want the JDK to reify the version value as a specific object with weird rules,
> why not considering that it can be any string (like in the JVM classfile format) ?
>
> regards,
> Rémi
>
> ----- Mail original -----
>> De: "David M. Lloyd" <david.lloyd at redhat.com>
>> À: jpms-spec-experts at openjdk.java.net
>> Envoyé: Lundi 21 Mars 2016 20:44:35
>> Objet: Re: Missing issue: Version string format
>>
>> On 03/21/2016 10:43 AM, David M. Lloyd wrote:
>>> On 03/21/2016 08:49 AM, David M. Lloyd wrote:
>>>> On 03/11/2016 04:13 PM, David M. Lloyd wrote:
>>>>> The current java.lang.module.ModuleDescriptor.Version class contains the
>>>>> comment:
>>>>>
>>>>> "Vaguely Debian-like version strings, for now.
>>>>> "This will, eventually, change."
>>>>>
>>>>> At some point the syntax and semantics of version designators has to be
>>>>> worked out and agreed upon.  Ideally the scheme would be compatible with
>>>>> as many existing widely deployed schemes as possible in terms of allowed
>>>>> syntax, and as much as possible, collation order (at least within the
>>>>> context of other modules from the same versioning scheme).
>>>>
>>>> Judging from the lack of response, I assume that nobody has done any
>>>> work on this, so I have a proposal.
>>>
>>> I just updated to the latest code and it looks like last week the scheme
>>> was updated.
>>>
>>> I would reframe this discussion into a proposal a few changes from the
>>> existing code.
>>>
>>> • Addition of a few more separator characters: the new code supports
>>> "+", "-", and ".", and also the transition types.  It does not support
>>> "_" which I believe to be in fairly wide use.  I would propose that this
>>> character be added as a valid separator.
>>> • The current code uses multiple "classes" of separators, which also
>>> depend on their location within the version string.  I suggest that if
>>> possible, a version sequence be agnostic to scheme, or else make
>>> versions layer-specific (similar to the #ModuleNameCharacters issue); I
>>> think the scheme I outlined would support all of the currently supported
>>> schemes with little or no adjustment.
>>> • The implementation is probably considerably heavier than it needs to
>>> be in terms of objects.  A zero-object representation is possible, as is
>>> a one- or zero-object tokenizer/validator.
>>>
>>> Unless someone has an early strong disagreement, I will prepare a
>>> prototype to illustrate the changes.
>>
>> I want to expand on this just a little more.  I think it is worth
>> dividing the concept of a version scheme from the concept of syntax of a
>> version string.  The former should be specific to a layer, and the
>> latter should be (if possible) global.  This allows layers to enforce
>> policy that makes sense to that layer, while also allowing predictable
>> (if not intuitive) interoperability between version schemes.
>>
>> My change will create a general parsing scheme for versions as
>> previously described, and move the specific validation rules to the
>> existent layers to which they are relevant, as necessary to pass tests.
>> --
>> - DML
>>

-- 
- DML