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

[Iris Clark]

Hi, Joe.

Thanks for the review comments.

>>>     http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/

> 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?

No.  Downstream users may provide their own specialization, but
there is no requirement that they must do so. 

jdk.OracleVersion has been removed.  The functionality it provided, 
access to the fourth element of the version number, is trivially 
accessed by existing methods in jdk.Version.

I've filed the following bug to address the more general use case:

    8145793:  Provide vendor-specific interpretation of a JDK version string
    https://bugs.openjdk.java.net/browse/JDK-8145793

> The equals / hashCode behavior of Version and OracleVersion is bit 
> surprising and I think somewhat underspecified given the possibility 
> of defining subclasses.

Given the above regarding downstream use, I've make jdk.Version final
and the constructor is now private.  Oracle or any other JDK 
distribution wishing to impose additional semantics to the version 
string interpretation will need to do so via encapsulation rather 
than inheritance.

> How is this API supposed to behave if the component version strings have a 
> numerical value greater than Integer.MAX_VALUE?

>From the specification of the only instance method, Version.parse():

     * @throws  NumberFormatException 
     *          If an element of the version number or the build number cannot
     *          be represented as an {@link Integer}

> Was using Longs to record numerical versions rather than Integers 
> considered?

Yes.  In an informal poll conducted during implementation, it was 
thought that 2^32 bits would be more than sufficient to represent 
the components of typical version numbers.

An updated webrev is forthcoming.

Thanks,
iris

PS:  I believe that we are both out the week of 21 December, so I don't
expect to hear back from you until the New Year.