RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Fri Nov 27 14:36:42 UTC 2015
On 2015-11-25 02:54, Iris Clark wrote:
> Please review the new classes jdk.Version and jdk.OracleVersion. These are
> simple Java APIs to parse, validate, and compare version numbers.
> 8072379: Implement jdk.Version and jdk.OracleVersion
I thought the end agreement was that the + should always be present even
if build was empty, if opt was present but not pre. That is, "9-foo"
should unambigiously parse as vnum=9 and pre="foo", while "9-+foo"
should umambigously parse as vnum=9 and opt="foo". The javadoc does not
seem to reflect this.
I've also had to read and re-read the regexp and parsing logic in the
constructor to convince myself that this (most likely) will be correctly
handled. Perhaps a few comments around this would be helpful?
The comparison of two version strings which differs only in "pre" does
not adhere to the principle of astonishment.
The documentation states: "Pre-release identifiers are compared
numerically when they consist only of digits, and lexiographically
otherwise. Numeric identifiers are considered to be less than
non-numeric identifiers." But consider the following version strings:
That sequence would be ordered like this, which I find highly surprising.
I'm also surprised that equals() does not produce the same result as
compareTo(). If opt is to be ignored, surely it should be so in equals()
> The .java files are predominantly javadoc. The code is relatively
> jdk.Version is the representation of the JDK version string as described in
> JEP 223 (, 8061493). The javadoc is largely taken from the description
> section in the JEP. The API is described in the "API" section.
> jdk.OracleVersion extends jdk.Version and is the representation of the Oracle
> JDK version string. Its only purpose is to interpret the fourth element of
> the version number as a patch release.
> There are some minor discrepancies between the implementation and the JEP.
> The JEP will need to be updated. The most notable is the name of the package
> ("jdk" vs. the original "jdk.util"). The rename was recommended by Mark.
>  http://openjdk.java.net/jeps/223
More information about the core-libs-dev