RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

[Iris Clark]

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 at openjdk.java.net
Cc: verona-dev at 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