Missing issue: Version string format
David M. Lloyd
david.lloyd at redhat.com
Tue Mar 22 00:56:46 UTC 2016
I'd be okay with that personally. It would certainly be less code. :)
Having a general version syntax and collation system is generally useful
but it's a bit more of an abstract sort of usefulness.
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
More information about the jpms-spec-experts
mailing list