On Tue, 19 Jul 2022 20:18:14 GMT, Andy Goryachev <[email protected]> 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
