Re: hashCode() for Custom classes
Patricia Shanahan wrote:
More generally, it seems unlikely to me that hash codes are uniformly
distributed over all the int values. I would expect values close to zero
to be overrepresented. Many classes with a small number of possible
object values have a contiguous hash code range, often including zero.
For example, the Short hash codes have range [-32768, 32767].
Uniform distribution is not a requirement for hashCode(). Low probability of
collision between non-equal instances is the requirement. The hash of Short
keeps that guarantee.
Considering Integer, zero is the hash exactly for instances that compare equal
to Integer.ZERO. Instances that do not compare equal to that value will not
collide.
Empty Sets hashing to zero could increase collisions with, say, Sets
containing only a 'null', but the likelihood of two Sets colliding somewhere
in a real-world situation because of that, and thereby causing an unacceptable
consequence, is acceptably low. In fact, it might not at all be unreasonable
where this type of collision is known to be possible (e.g., you decide to
allow in 'null' values), to filter out that case prior to examination of any
hash codes.
One or two extra calls to equals() for corner cases is not usually bad, even
if they are slightly above average statistically. Where such cases do matter,
one might skew the hashCode() to return different ints for subtly different
values like null vs. empty, or one might build different handling for the
corner cases that skips hashCode() altogether.
The non-uniformity that Patricia observes seems both conformant to
non-uniformity in the domains represented by the hashes, and not inconsistent
with the purpose of hashCode().
--
Lew