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:
> Hi.
> Please review the new classes jdk.Version and jdk.OracleVersion.  These are
> simple Java APIs to parse, validate, and compare version numbers.
>    Bug
>      8072379: Implement jdk.Version and jdk.OracleVersion
>      https://bugs.openjdk.java.net/browse/JDK-8072379
>    Webrev
>      http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/

Hi Iris,

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() 
as well?


>    JavaDoc
>      http://cr.openjdk.java.net/~iris/verona/8072379/doc.1/jdk/Version.html
>      http://cr.openjdk.java.net/~iris/verona/8072379/doc.1/jdk/OracleVersion.html
> The .java files are predominantly javadoc. The code is relatively
> straight-forward.
> jdk.Version is the representation of the JDK version string as described in
> JEP 223 ([0], 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.
> Thanks,
> iris
> [0] http://openjdk.java.net/jeps/223

More information about the verona-dev mailing list