Overriding hashCode() when overriding equals() [duplicate]

Question

Possible Duplicate:
In Java, why must equals() and hashCode() be consistent?

I read that one should always hascode() when overriding equals().

Can anyone give a practical example of why it might be wrong otherwise? i.e. Problems that might arise when overriding equals() but not hashCode().

Is it necessary to write a robust hasCode() function whenever we override equals()? Or a trivial implementation is enough?

For example,

A poor implementation such as the below is good enough to satisfy the contract between equals() & hashCode()?

public int hashCode() {
   return 91;
}

Answer 1

Both equals and hashcode are based on the principle of object's unicity. If equals returns true the hashcode of both objects must be the same, otherwise hash based structures and algorithms could have undefined results.

Think of a hash based structure such as a HashMap. hashcode will be invoked as a base to get the key's reference, not equals, making it impossible in most cases to find the key. Also, a poor implementation of hashcode will create collisions (multiple objects with the same hashcode, which one is the "correct" one?) that affect performance.

IMHO, overriding equals OR hashcode (instead of overriding both) should be considered a code smell or, at least, a potential bugs source. That is, unless you're 100% sure it won't affect your code sooner or later (when are we so sure anyway?).

Note: There are various libraries that provide support for this by having equals and hashcode builders, like Apache Commons with HashcodeBuilder and EqualsBuilder.