Re: equals and hascode
Aeris wrote:
A ?good? implementation of equals is
public boolean equals(Object obj) {
if(this == obj) {
return true;
}
if (obj == null || !(obj instanceof MyClass)) {
return false;
}
return this.hashCode() == obj.hashCode();
}
That is a very, very, /bad/ implementation of equals(), except in the extremely
rare cases where some class's instances' states are entirely reflected in their
hashCode()s. I.e. that each unique (up to whatever notion of equality is
appropriate for that class) object has a unique hash code. That is hardly ever
going to be true.
Still, you are correct that it good practice to override hashCode() if you
provide your own implementation of equals(). But it's worth mentioning that not
doing so isn't necessarily a /bug/, although it's unusual. It just means that
the objects in question /must not/ be put in HashSets, or used as keys in
HashMaps (and similar).
I haven't check the Colt code, but I assume Colt Matrixes are mutable (you can
set their elements), and that their notion of equality is based on equality of
their contents. If so then, even if a suitable version of hashCode() were
provided, it would /still/ be a serious lurking bug to put one into a HashSet,
since its hashCode() would change whenever you changed an element. Thus
breaking the HashSet.
In the circumstances, I'd have been tempted to make Matrix.hashCode() throw an
unchecked exception...
-- chris