RFR: 8289389: Fix warnings: type should also implement hashCode() since it overrides Object.equals() [v4]

[John Hendrikx]

On Thu, 21 Jul 2022 12:29:38 GMT, Tom Schindl <tschindl at openjdk.org> wrote:

> > I really must wonder at some of these changes. They seem... unnecessary. Just because equals is overridden, doesn't mean hashCode must be as well, especially not if the objects involved are mutable -- it might in fact be better to leave it alone or return a constant value from it (or only use immutable fields).
> 
> This not true - there's a contract between `hashCode` and `equals` quoting the JavaDoc of `hashCode()`:

Thanks, I'm well aware. The issue here is that once a mutable object is stored in a map, you can have either:

1) Have it find and match the same instance of the object (by not overriding `hashCode` or calling `System.identityHashCode()`), regardless of whether that object was mutated in the mean time
2) Have it find and match any instance (by overriding `hashCode` and using the same mutable fields as `equals` uses), but only if the original instance wasn't mutated in the mean time (its bucket will not be adjusted by hash map) 
3) Have it work in all cases, but with terrible performance (by overriding `hashCode` with the suggested `getClass().hashCode()` which is effectively a constant)

This isn't mentioned anywhere aside from the small note ("provided no information used in {@code equals} comparisons on the object is modified").

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

PR: https://git.openjdk.org/jfx/pull/821