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:

9-01
9-01a
9-02
9-003b

That sequence would be ordered like this, which I find highly surprising.
9-01
9-02
9-003b
9-01a

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?

/Magnus

>
>    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 core-libs-dev mailing list