RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v11]

[Roger Riggs]

On Wed, 10 Jan 2024 14:58:37 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigInteger.java line 3998:
>> 
>>> 3996:         int i = ArraysSupport.mismatch(m1, m2, len1);
>>> 3997:         if (i != -1)
>>> 3998:             return Integer.compareUnsigned(m1[i], m2[i]) < 0 ? -1 : 1;
>> 
>> Just an observation.  The (Java and intrinsic) implementation of Integer.compareUnsigned already returns -1, 0, 1.
>> Returning `Integer.compareUnsigned(m1[i], m2[i])` would yield the same result without the tertiary expression.
>
> Yes, that's what was proposed [here](https://github.com/openjdk/jdk/pull/14630#discussion_r1242245875) some time ago.
> 
> But the spec of `compareUnsigned()` does _not_ guarantee a -1, 0, 1 result, so there's a (minimal) risk when returning its value directly. (For some reason, `BigInteger` specifies a -1, 0, 1 outcome.)

In expressing intent, perhaps `Integer.signum(Integer.compareUnsigned(m1[i], [m2[i]))`.
Though it may all be for nothing if C2 can optimize it away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14630#discussion_r1447521230