CODEWITHSUNDEEP
javahashhashmaphashcode
Roam
Roam

Reputation: 4949

Why is value of a value class as its hashCode "not a good idea"?

The very last paragraph of Item 9 of Effective Java, 2nd Edn, J. Bloch says that, for value classes like Integer, String, Date etc, returning a function of the the exact value of that class as the hashCode isn't a good idea.

So, the class Integer returning the value of the integer it represents as the hashCode of its instance isn't all so good.

Neither is the hashCode() of String returning an integer value directly mapped from the overall content, i.e., the characters that the String instance has.

These hashCode()-s clearly comply with the contract.

To me, it seems to be a good idea rather than a bad one-- the hashCode-s vary as the values vary across objects, and these hashCodes are "normalized" before they are spread out into the buckets of a HashMap/HashSet-- so that the hashCode-s of the entries do not form a bias on which bucket the entry will go in.

What am i missing here - what makes mapping the class value directly to hashCode a "bad idea"?

TIA

//===========================

EDIT

pls also see comments under Steve Siebert's answer in relation to this.

Upvotes: 5

Views: 199

Answers (3)

Sotirios Delimanolis
Sotirios Delimanolis

Reputation: 280072

The full quote is

Many classes in the Java platform libraries, such as String, Integer, and Date, include in their specifications the exact value returned by their hashCode method as a function of the instance value. This is generally not a good idea, as it severely limits your ability to improve the hash function in future releases. If you leave the details of a hash function unspecified and a flaw is found or a better hash function discovered, you can change the hash function in a subsequent release, confident that no clients depend on the exact values returned by the hash function.

Emphasis mine. The book is just stating that it is generally considered bad practice to reveal implementation details in a specification. This makes it resistant to change.

The fact that it was implemented as returning an exact value (for Integer) or some calculated value (for Date and String) is not bad.

Upvotes: 3

Steve Siebert
Steve Siebert

Reputation: 1894

What it's saying is that those javadoc specification say exactly how the hashCode is created. By doing so, applications can now depend on this always to be true...and now those implementations can never change the way that the hashCode is generated.

It doesn't mean that you shouldn't derive your hash from your values...just don't tell people how you do this in your specification =)

Upvotes: 4

Mark Jeronimus
Mark Jeronimus

Reputation: 9541

The Java API does just that, it returns the integer.

Integer t = ...;
t.intValue() == t.hashCode(); // true

I have the same book at work. I'll look at it on Monday.

If you're really worried, implement the FNV-1a hash:

    int hash = 0x4C1DF00D;
    hash = (hash ^ value) * 0x01000193;

Upvotes: -1

Related Questions