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