On Tue, 7 Dec 2021 08:28:47 GMT, Сергей Цыпанов <d...@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
