If an object is mutable, then their identity needs to stay with the object instance, not with the data. In .NET, I tend to only override GetHashCode and Equals on structs and sealed classes.

If you need a way to compare the values of two instances, you can always add a “Matches” method.

If you need to look mutable objects up in a hashtable, consider a custom hashcode/equality provider (I assume this is possible in Java).

It isn’t. Or it’s “solved” by documenting the limitations:

From: http://www.go-mono.com/docs/index.aspx?tlink=8@ecma%3a147%23Hashtable%2f

“Objects used as keys in a Hashtable is required to either implement both System.Object.GetHashCode and System.Object.Equals(System.Object) or neither. Furthermore, for a particular key, these methods are required to produce the same results when called with the same parameters while that key exists in a particular Hashtable . Keys cannot be mutated while they are used in the table.”

If you think about it, it’s really the only sane way to go (for precisely the reasons Rentar specifies): if your hash value changes when members change (as it should!), if you change the hash value of an existing key within a hashtable it will no longer be in the right “bucket” of the hashtable, or in the correct position for RBL trees, etc. Meaning that you can never find that entry again.

How else would you like it to compute a hash value? The only alternative I can think of would be to use some kind of identity-based hash code (such as produced by System.identityHashCode() or the default implementation of Object.hashCode()). But then you could never check wether the HashSet contains an object that equal()s another object you’ve got (or you could only check that by calling equal() on each object in the set, which kind of defeats the purpose of a HashSet).

You’ve also got the same problem with the keys in a HashMap: they must not change or the behaviour is unspecified. But I’ve never found that to be a problem …

How’s that solved in .NET?

(I agree that the documentation could be a bit clearer, but as the Bugreport mentions the documentation is in Object.hashCode() and .equals() and clearly specified in their contract).