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

[John Hendrikx]

On Tue, 19 Jul 2022 20:18:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> John, thank you for your comments!
> 
> I fully agree with the idea of not putting objects with mutable fields that participate in either equals() or hashCode() into Hashtable. This scenario might still be legitimate, for example by not modifying the fields in question after instantiation.

Risky, but that's on the user... they'll have to check the source code to see how hashCode is implemented before doing this kind of thing.

> I also agree that some of the changes might look unnecessary, or perhaps we should either return super.hashCode() or maybe getClass().hashCode() -- not a constant, as hashCode() guarantees some variability, while a constant does not.

Yes, `getClass().hashCode()` is recommended, it is constant for all instances of that class.

> I do think, however, that suppressing this warning or turning it off is not a good idea. it forces the developer to think about exactly this issue.

Yeah, I suppose you can "surpress" the warning by overriding it with `getClass().hashCode()` if there are no immutable fields. Even though performance would suffer, it would at least be working correctly all the time if someone accidently put these in a hashed collection.  Once the problem is discovered and the developer realizes their mistake, they can always wrap the object to provide a hash code more suitable to their purpose.

I think many of these have `equals` implemented primarily because they're used as values for properties. These need `equals` because of how changes are detected.

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

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