A common error is to override Object.equals() without
See "Bloch, Effective Java", Item 8
Logged In: YES
... or vice versa. Check for both.
Logged In: YES
The original request has been implemented in CVS and will be
available in Checkstyle Version 3.
kcrca, I'm not not sure why it's necessary to override
equals() if you override hashCode(). What exactly goes wrong
if you don't override equals()? Maybe you can post an
example to the checkstyle-devel mailing list. It's no
problem adding this direction, but please convice me that it
I'll answer here -- I'm not on checkstyle-devel so I'm a little loathe
to post there myself. Feel free to forward if that's useful.
The language specifiction requires the following always be true: If
x.equals(y), then x.hashCode() == y.hashCode(). The idea is that if
you override equals to define a new meaning for equivalance but do not
override hashCode, then two objects might have equals return true, but
(using the inherited hashCode) have different hashCode values.
But the problem works the other way. An implementation of hashCode that
is out of sync with equals is a problem. It doesn't matter which
method is missing. For example, if String only overrode hashCode to
hash equivalent strings to the same value, but didn't override equals,
then hashing would get you to the right bucket but you still wouldn't
find the correct string because equals would return false.
In essence, equals defines an equivalence mapping with which hashCode
should be coordinated. Although one can imagine places where a subclass
might improve on hashCode without breaking faith with equals, it is far more
likely that the programmer forgot to override hashCode along with equals.
(I've programmed Java for as long as it has been released and I have
never written or even seen such a case.)