Brendon McCullum wrote:For the first one, I'm quite clear that overriding equals only will break the contract since logically equal objects will have different hashcodes.
But the second part is a bit confusing. If I only override hashcode (though I know this won't benefit me at all in any scenario), I don't think it violates any of the 3 points mentioned in the contract. Please correct me if I'm wrong.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:No, you're not wrong, unless you implement it in such a way that it could return a different hash code when two objects are equal; which is why:
public final int hashCode() { return 17; }
is ALWAYS valid.
However, it offers nothing that Object.hashCode() doesn't already, and is absolutely horrible, performance-wise, for hashed datasets.
Winston
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
Campbell Ritchie wrote:Afraid it does violate the general contract of hashCode. It says the hash code should remain unchanged as long as no information used by equals changes.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
No, it doesn't. It returns the same result as a defaultWinston Gutkowski wrote:. . . Object.hashCode(), by default, violates its own principle.
That would be too easy.Why not just say it outright: if you implement equals(), you MUST implement hashCode(), and NOW here are the rules....
Winston
It says that elsewhere.The Object#equals documentation wrote:it is generally necessary to override the hashCode method whenever this method is overridden