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

[joe darcy]

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