<i18n dev> RFR: 8277868: Use Comparable.compare() instead of surrogate code [v3]

[Alexey Ivanov]

On Tue, 7 Dec 2021 08:28:47 GMT, Сергей Цыпанов <duke at openjdk.java.net> wrote:

>> Instead of something like
>> 
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>> 
>> we can use `return Long.compare(x, y);`
>> 
>> All replacements are done with IDE.
>
> Сергей Цыпанов has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8277868: Inline local var

src/java.base/share/classes/java/util/Calendar.java line 3420:

> 3418:     private int compareTo(long t) {
> 3419:         long thisTime = getMillisOf(this);
> 3420:         return Long.compare(thisTime, t);

Probably, in this case `thisTime` variable can also be dropped.

src/java.base/share/classes/java/util/Date.java line 977:

> 975:         long thisTime = getMillisOf(this);
> 976:         long anotherTime = getMillisOf(anotherDate);
> 977:         return Long.compare(thisTime, anotherTime);

Looks like local variables can also be dropped here as each value is used once.

src/java.base/share/classes/java/util/UUID.java line 517:

> 515:         return (this.mostSigBits < val.mostSigBits ? -1 :
> 516:                 (this.mostSigBits > val.mostSigBits ? 1 :
> 517:                  Long.compare(this.leastSigBits, val.leastSigBits)));

In this case Javadoc specifies only -1, 0 or 1 can be returned. `Long.compare` does not specify this but returns these values. Couldn't it cause any problems in the future if implementation of `Long.compare` is changed?

Does it make sense to use `Long.compare` for `mostSigBits` too?

int mostSigBits = Long.compare(this.mostSigBits, val.mostSigBits);
return mostSigBits != 0 ? mostSigBits : Long.compare(this.leastSigBits, val.leastSigBits);

-------------

PR: https://git.openjdk.java.net/jdk/pull/6575