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