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

[Iris Clark]

Hi, Magnus.

Thanks for taking the time to look at this again.

> I noted that your java source file had a lot of initial tabs instead of spaces. 
> I'm not sure if we have any code guidelines about this, 

jcheck prevents tabs in comments and source.  I remove them, one of my
editors adds them when I make changes.  It's annoying.

They won't be in the checked in source.

Regards,
iris

-----Original Message-----
From: Magnus Ihse Bursie 
Sent: Thursday, January 14, 2016 3:38 AM
To: Iris Clark; Joe Darcy; Mandy Chung; Roger Riggs; Alan Bateman
Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

On 2016-01-11 22:44, Iris Clark wrote:
> Hi, Joe, Roger, Alan, Magnus, and Mandy.
>
> At the end of December (shortly before the Christmas/Winter break and 
> my vacation), I provided responses to your messages and an updated 
> webrev:
>
>    http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/
>
> I didn't hear from anybody, so I'd like to optimistically assume that 
> you were satisfied.  Is that correct?

I'm basically happy. As other reviewers, I think the regexes are a bit tough to parse (regexes always are), and some additional comments on the effect would be appreciated. Thanh Hong Dai had some good suggestions as well on how to improve readability.

I noted that your java source file had a lot of initial tabs instead of spaces. I'm not sure if we have any code guidelines about this, but I have not encountered that in the JDK source base before, so I'd recommend you turn them into spaces.

/Magnus


>
> For you convenience, here's a reference to the December and November
> threads:
>
>      http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html
>      
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036
> 904.html
>
> I'd like to wrap up this work for the initial implementation of 
> jdk.Version soon.
>
> Regards,
> iris
>
> -----Original Message-----
> From: Iris Clark
> Sent: Friday, December 18, 2015 1:55 PM
> To: Joe Darcy; Mandy Chung
> Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
> Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
>
> 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.