Sure thing. Glad to see this going in. Mandy
> On Feb 2, 2016, at 7:17 PM, Iris Clark <iris.cl...@oracle.com> wrote: > > Hi, Mandy. > > Thanks so much for pushing the changeset for the initial implementation > of jdk.Version! > > Regards, > iris > > -----Original Message----- > From: Iris Clark > Sent: Monday, January 11, 2016 1:45 PM > To: Iris Clark; Joe Darcy; Mandy Chung; Magnus Ihse Bursie; Roger Riggs; Alan > Bateman > Cc: core-libs-dev@openjdk.java.net; verona-...@openjdk.java.net > Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion > > 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? > > 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/036904.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@openjdk.java.net; verona-...@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.
