RFR: 8290973: In AffineTransform, equals(Object) is inconsistent with hashCode()

[Phil Race]

On Fri, 10 Jun 2022 09:39:48 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

> `AffineTransform.equals(Object)` and `hashCode()` break two contracts:
> 
> * `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
> * `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.
> 
> This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.

I've run all tests we have and not too surprised they pass since the affected values
probably aren't being exercised.

However I've been reading the docs about NaN and +/-0 equivalence at
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Double.html
since if we change anything it probably ought to align with what ever says there.

Since I recalled that NaN == NaN will always return false, it seemed what you have
was not consistent with that. Whilst this is true it seems Double.equals() does the opposite .. so OK ..
although it surprised me.

But then the docs say +0 and -0 should not be equal whereas for backwards compatibility
you say you extended them being treated as equal from equals() into hashCode() ..

Not sure why only in this case was the compatibility important.

I'd like to hear what  @jddarcy (Joe Darcy) thinks about all of this.

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

PR: https://git.openjdk.org/jdk/pull/9121