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

[joe darcy]

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