4 ms·
> That's a fundamental misunderstanding of hashCode Right. So the parenthetical clause should more correctly state "(or worse, adding them to hashCode but not
by lucumo 2y ago
> That's a fundamental misunderstanding of hashCode
Right. So the parenthetical clause should more correctly state "(or worse, adding them to hashCode but not equals)". That's fine, but it's still the same problem: there's a hidden dependency between changes in two or more locations. People make errors in those kind of updates all the time.
- xxs 2y ago>or worse, adding them to hashCode but not equals That's proper bad, however it should be noted in a pull request and explained how hashCode operates - people learn and improve. > there's a hidden dependency between changes in two or more location True, of course. However, just do not modify hashCode and consider if the extra fields do contribute to equality either. Realistically I have not seen this error since very early 00s. I have seen use of mutable fields in hashCode, though (and the latter being modified while added to a hashset, used as map keys. lombok encourages such designs). Another a lot more common error is "compareTo"