On Thu, 21 Jul 2022 12:29:38 GMT, Tom Schindl <tschi...@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
