RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

[joe darcy]

PPS Perhaps this is already planned as future work, but it might be a 
kindness to those analyzing JDK version strings if there was a class 
that did a "best effort" at understanding Sun and Oracle JDK version 
strings pre-Verona to those post-Verona. In other words, a version class 
where

     new JdkVersion("1.8.0_25")

would have major() == 8 and minor() == 25, but have the specified 
meaning for strings for Verona strings where the first group was 
numerically 9 or larger.

Cheers,

-Joe

On 11/25/2015 3:57 PM, joe darcy wrote:
> PS If the concepts the two classes Version and OracleVersion are 
> trying to capture is a "Vendor-Version" then perhaps that can be 
> surfaced more directly in the API. That is, if the basic notion is to 
> interpret a version string in a way appropriate to and specialized for 
> a given vendor of the JDK (a la the java.vendor system property), then 
> perhaps a type like
>
> // API sketch
> public final class VendorVersion {
>     public VendorVersion(String vendor, Version version, 
> Comparator<Version> versionComp>) { ...}
>
>     @Override
>     public boolean equals(VendorVersion vv) {
>         // Usual instance of checks
>         return Objects.equals(vendor, vv.vendor()) && 
> versionComp.version(), vv.version());
>     }
>
>     int compareVersion(VendorVersion vv) {
>         if (!vendor.equals(vv.vendor()))
>             // throw an exception
>         return versionComp(version, vv.version);
>     }
>
>     // ...
> }
>
> might serve the purposes at hand.
>
> HTH,
>
> -Joe
>
> On 11/25/2015 1:31 PM, joe darcy wrote:
>> Hello,
>>
>> On 11/25/2015 8:48 AM, Mandy Chung wrote:
>>>> On Nov 24, 2015, at 5:54 PM, Iris Clark <iris.clark at oracle.com> wrote:
>>>>
>>>> Hi.
>>>>
>>>> Please review the new classes jdk.Version and jdk.OracleVersion.  
>>>> These are
>>>> simple Java APIs to parse, validate, and compare version numbers.
>>>>
>>>>   Webrev
>>>>
>>>> http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/
>>> This looks good to me.  Alan raises a good question whether 
>>> jdk.OracleVersion is intended to be pushed to OpenJDK.
>>>
>>>
>>
>> I share the concerns that have been raised about the naming and 
>> placement of a class named "OracleVersion".
>>
>> Is the intention that downstream JDK distributions, such as IcedTea, 
>> whether based on OpenJDK or otherwise, would provide their own 
>> specialization of the jdk.Version class?
>>
>> If so, should there be some kind of provider interface to find 
>> system's the version interpreter?
>>
>> For example, what class, if any would be expected to provide detailed 
>> analysis of the version string emitted by, say, a OpenJDK build used 
>> as the reference implementation of Java SE 9?
>>
>> The equals / hashCode behavior of Version and OracleVersion is bit 
>> surprising and I think somewhat underspecified given the possibility 
>> of defining subclasses.
>>
>> The (overridable) equals method in Version says "Two Versions are 
>> equal if and only if they represent the same version string." If that 
>> is interpreted to mean the Versions are equal if their toString 
>> output is equal, the toString spec says "Returns a string 
>> representation of this version." and the (overridable) implementation 
>> in Version looks at versions, pre, build, and optional.
>>
>> Since OracleVersion does not override equals, a plain Version object 
>> and an OracleVersion object can compare as equal. Additionally, a 
>> VersionWithDifferentToStringOutput("1.2.3") object which overrides 
>> toString would not be semantically equivalent to a Version("1.2.3") 
>> object. Worse, there could be a non-communicability behavior in the 
>> equals method since
>>
>>     (new Version("1.2.3")).equals(new 
>> VersionWithDifferentToStringOutput("1.2.3"))
>>
>> could return "true" while
>>
>>     (new VersionWithDifferentToStringOutput("1.2.3")).equals(new 
>> Version("1.2.3"))
>>
>> could easily and legitimately return "false" by the specification.
>>
>> How is this API supposed to behave if the component version strings 
>> have a numerical value greater than Integer.MAX_VALUE?
>>
>> Was using Longs to record numerical versions rather than Integers 
>> considered?
>>
>> Thanks,
>>
>> -Joe
>