Re: hashCode
Jan Burse wrote:
There is no reference to Comparable and the compareTo. If I am not
True.
using HashMap or HashSet in my application, and still override
equals, I do not need to implement hashCode(). I could for example
True.
use TreeMap or TreeSet and implement the Comparable interface. There
is a reference to equals() back from Comparable though.
This requires a detailed knowledge of the implementation of the particular
'Map' or 'Set'. If its searches do not employ hash codes, then you do not need
to implement 'hashCode()' for value-equal types.
In the general case one prefers to underspecify the mechanics, that is, allow
a client of the type to deploy either 'equals()'-based or hash-based
algorithms, by ensuring the methods are consistent with each other per Joshua
Bloch and other notables.
http://docs.oracle.com/javase/6/docs/api/java/lang/Comparable.html
Even for cases where one predicts the use will not require one or another of
the consistency practices, it is harmless to enforce them.
There are four methods a type might use to represent equality or identity and
deviations therefrom: 'equals()' of course, and 'hashCode()', 'compareTo()',
and 'toString()'. There may be external 'Comparator's on that type.
All these methods on or of a type, where they exist, should be consistent,
absent an overwhelming and sound reason not to be.
The default case from 'Object' is that 'equals()' implements ==, 'hashCode()'
returns something sort of like an address of the instance which is nearly
always unique within a given JVM run, 'toString()' returns a decorated string
version of the hash code, and 'compareTo()' doesn't exist.
To express value equality in a type, one must override 'equals()'. The rest
are optional in Arne's strictest and most correct use of that notion. It is
also harmless to keep the rest consistent and nearly always (as in you might
encounter one instance per career otherwise) useful.
One generally chooses 'TreeMap' for its sorting capability, not its reliance
on 'equals()' vs. 'hashCode()' to achieve that. (Assuming it has such a
reliance.) Unless there's a compelling argument to rely on 'TreeMap''s
undocumented non-use of hash codes, why do so?
Yes, I am aware that the 'TreeMap' documentation makes it clear that
'hashCode()' shouldn't be involved. Without promising it isn't. But a
'Comparator' might use hash codes under the hood in a naive attempt to
shortcut a comparison, not knowing that the base type assumes no one would do
such a thing. Or some later client might need only equality and not order, and
throw the base type into a 'HashMap' with surprising results.
Should you design anything that violates the consistency rule, then please do
both Javadoc and code-comment it properly.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg