Suggest Double.compare in ObjectEqualsForPrimitives

[findepi]

Objects.equal(a_double, another_double) and a_double == another_double have different semantics (different result when both compared values are NaN). Suggest replacement using Double.compare to avoid changing code semantics. This is especially relevant when implementing equals methods.

Fixes #4392

[findepi]

@cushon can you please approve the build to run?

cc @msridhar you might be interesting in this in context of automated code fixes.

[cushon]

We have some internal guidance to use Double.toLongBits when implementing exact equality on doubles if the values could be NaN, instead of Double.compare. What do you think of that alternative?

I'm also wondering if we should exclude double and float from this change, since it's just a micro-optimization, and there's a readability tradeoff with using Double.compare or Double.toLongBits

[findepi]

@cushon thank you for your review!

We have some internal guidance to use Double.toLongBits when implementing exact equality on doubles if the values could be NaN, instead of Double.compare. What do you think of that alternative?

Double.doubleToRawLongBits is obviously not a suitable replacement, since it compares two different NaN representations as numerically different, while Double.equals(Object) compares them as equal (and so does Double.compare(double, double).

Double.doubleToLongBits looks as a good alternative & may perform better, changed the PR, thanks!

Would you mind triggering the build again?

I'm also wondering if we should exclude double and float from this change, since it's just a micro-optimization, and there's a readability tradeoff with using Double.compare or Double.toLongBits

i am not sure i understand. Can you please rephrase?

[cushon]

I'm also wondering if we should exclude double and float from this change, since it's just a micro-optimization, and there's a readability tradeoff with using Double.compare or Double.toLongBits

i am not sure i understand. Can you please rephrase?

I was wondering about having ObjectEqualsForPrimitives not emit findings for double and float. There's a tradeoff between Objects.equal(a_double, another_double) and Double. toLongBits(a_double) == Double. toLongBits(another_double), the latter avoids some boxing and is theoretically faster, but the first is potentially more readable.

[findepi]

Sure, I can do that.

[findepi]

@cushon Would you mind triggering the build again?

[findepi]

@cushon thanks for approval.
I see the JDK EA on ubuntu-latest build is failing. I don't know how to fix it.

[cushon]

JDK EA is also failing at head, there are some breaking changes we'll need to prepare for before JDK 23 is released, but it doesn't need to be a blocker for this

[findepi]

thanks for the merge!

[findepi]

oh, and thanks for fixing the commit message.

[cushon]

thanks for the merge!

sure thing!

oh, and thanks for fixing the commit message.

@cpovirk gets the credit for that part :)