Hi, Joe.
You make a good point regarding the inconsistency between compareTo (which
ignores $OPT) and equals (which includes $OPT). To resolve this difference, I
will introduce two new methods so that users may choose to uniformly consider
$OPT in comparisons.
We now have the following:
public int compareTo(Version ob);
public int compareToIgnoreOpt(Version ob);
public boolean equals(Version ob);
public boolean equalsIgnoreOpt(Version ob);
The names parallel String.{compareTo|equals}{IgnoreCase}*.
I've re-arranged the code a bit around the implementation and tests for
equals*() and compareTo*() to take advantage of code re-use.
Thanks,
iris
-----Original Message-----
From: joe darcy
Sent: Monday, November 30, 2015 5:33 PM
To: Magnus Ihse Bursie; Iris Clark; core-libs-dev@openjdk.java.net
Cc: verona-...@openjdk.java.net
Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
Another comment below...
On 11/27/2015 6:36 AM, Magnus Ihse Bursie wrote:
> 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?
>
I'm one of the maintainers of BigDecimal, one of the few Comparable
classes in the JDK where compareTo is "inconsistent with equals" (see
"Effective Java, 2nd edition", Item 12 - Considering implementing
Comparable).
It is consistently surprising to users if compareTo is inconsistent with
equals ;-) Therefore, if at all possible it is preferable to have
compareTo be *consistent* rather than *inconsistent* with equals;
although there are cases where the inconsistency is necessary or at
least defensible.
I suggest providing multiple compareFoo methods for version that did or
did not include certain components, some of these could be consistent
with equals and others not.
HTH,
-Joe
