Hi Iris,
Catching up on old reviews, the regular expression for versions is given as
^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$
Is this equivalent to
^[1-9][0-9]*(\.[0-9])*
Trying to put this in words, "The version number starts with a sequence
of digits where the leading digit is not "0". Afterward, there are zero
or more period separated groups of digits with no restrictions on the
digits. Note that this implies The version number ends with a digit group."
I suggest changing the class-level javadoc discussing comparisons to
defer to the various compare methods. It would be helpful to not which
compare methods are consistent with equals and which are not.
Thanks,
-Joe
On 1/11/2016 1:44 PM, 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?
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.
