Alternative Version implementation

[David M. Lloyd]

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

-- 
- DML