Alternative Version implementation

[David M. Lloyd]

On 03/23/2016 09:38 AM, David M. Lloyd wrote:
> On 03/23/2016 09:20 AM, David M. Lloyd wrote:
>> I've gone ahead and written a new Version implementation that implements
>> the rules I've described.  It seems to work OK though I am having a hard
>> time running all tests locally due to some environmental problem that
>> I'm still working on, so I don't have a webrev yet.  But I do have a
>> diff that can be examined (and commented upon) at [1].
>>
>> The features of this implementation are:
>>
>> * Defines a single, unified version syntax and collation order without
>> defining a versioning policy
>> * Internally only contains one field, a String, which should provide a
>> minimal memory footprint compared to the multiple List approach
>> * Can be iterated piece-wise using a public Version.Iterator class (also
>> lightweight), which allows user-defined validation via e.g.
>> Predicate<Version> to be easily implemented
>> * Internal validation and collation logic uses a simple objectless
>> iteration (tokenizer-based) system by way of "cookie" values that
>> represent iteration state, which are reused by the aforementioned
>> Iterator class
>> * A bit more Unicode-friendly, as iteration operates on a code point
>> basis rather than on a character basis
>>
>> The unresolved issues of this implementation are:
>>
>> * It was my intention to apply Unicode normalization to the input
>> String, however the Version class is required to be used at an earlier
>> stage than Normalizer can be used so there's a bootstrap-related NPE if
>> that code is enabled
>> * There is no hook to provide a layer-specific validation policy;
>> Configuration seems to be the logical place for this but it's not clear
>> how it can be hooked in to the resolution process because of the tight
>> coupling between Configurations and resolution... resolving
>> #ModuleNameCharacters will probably provide an answer to this as well
>> * Needs additional dedicated tests (all testing thus far has been manual)
>> * Need to review/examine/discuss the collation rules (particularly
>> around separators), which I mainly just pulled out of my hat, to
>> determine what makes the most sense from a first-use perspective as well
>> as a compatibility perspective (OSGi, Maven, packaging systems etc.)
>>
>> I will follow up with a webrev at some point in the future unless anyone
>> wants to discuss or possibly reject this approach.  Rémi has already
>> pointed out that a plain version String is possibly the simplest/best
>> approach; I think part of this discussion must revolve around whether
>> unifying on a version system is desirable.  My position is that there is
>> value to be gained by unification (particularly around a common
>> collation scheme), but the compatibility path may be a tricky one.
>>
>> [1]
>> https://github.com/dmlloyd/openjdk-modules/compare/jigsaw/jake...version
>
> It was pointed out by Reinier Zwitserloot that the ordering I had
> proposed for numeric versus textual parts was backwards.  I've updated
> the code accordingly, but you can still see the previous version at this
> [2] link.
>
> [2]
> https://github.com/dmlloyd/openjdk-modules/commit/2fe57f574483814eee6b72f82111dc2b44952c2d

Later in this same discussion, Reinier argues that version pairs whose 
collation is conventionally ambiguous (e.g. 1.0 vs 1.0.0) should not be 
compared or collated at all.  I argued that a stable sort relationship 
is worth more in this case than undefined behavior, and that a stable 
sort is in fact an acceptable result when the expectation is that the 
result is undefined.  He followed up arguing that this kind of behavior 
*should* be defined, but as an error rather than a particular sort result.

The roles and behaviors of multiple types of separators was not brought 
up in this discussion but is probably relevant since it complicates the 
concept of conventional ambiguity.  I still favor a consistent, 
well-defined behavior which matches existing schemes to the maximum 
extent possible.

-- 
- DML