aspose file tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes hashCode() and equals() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of OCA Java SE 8 Programmer I Study Guide 1Z0-808 this week in the OCAJP forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "hashCode() and equals()" Watch "hashCode() and equals()" New topic

hashCode() and equals()

Shweta R Dhaneshwar
Ranch Hand

Joined: May 27, 2005
Posts: 35
I have read in some tutorials that hashCode() is properly implemented only if it returns same int value for multiple invocations of hashCode() method on same object.See the code below.hashCode() has been invoked twice on the same object.When you compile and run this code you get two different values.This example is from Dan Chisholm's.its the 8th question.multiple choices are given as follows.please explain why e is the right choice.

a. return 31;
b. return getI1();
c. return getI2();
d. return getI1() + getI2();
e. return 31 * getI1() + getI2();
f. None of the above


Shweta Dhaneshwar.<br />SCJP 1.4 90%
S Santhosh
Ranch Hand

Joined: Mar 03, 2005
Posts: 73
Originally posted by Shweta R Dhaneshwar:
I have read in some tutorials that hashCode() is properly implemented only if it returns same int value for multiple invocations of hashCode() method on same object...

My understanding is, when you say same object, the state of the object should not be changed(state here is the values of its member variables). Thats in your example if you create two objects with same i1,i2 values then the hash code returned should be same. But if i1,i2 values are different the object cannot be considered equal(but doesnt mean the hashcode has to be different...).

In short, Every time with same inputs the output hashcode on an object should be same.

You have given the choices, but whats the question?
Marc Marechal

Joined: Apr 15, 2005
Posts: 17
See in effective java programming Language Guide, item 8, to see a good way to make a hashCode().

'A good hash function tends to produce unequal hash codes for unequal objects. Ideally, a hash function should distribute any reasonable collection of unequal instances uniformly across all possible hash values.'

A rule is given.
In short, in your case, it will be :

public int hashCode()
result = 17;
result = result * 37 + getI1();
result = result * 37 + getI2();
return result;

So the answer E will best distribute unequals Test objects.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
First glance to me suggests you have violated the fundametal rule, "never calculate the hashCode from non-final fields".

Tony Morris
Java Q&A (FAQ, Trivia)
Philip Heller
Ranch Hand

Joined: Oct 24, 2000
Posts: 119
This would be easier if we knew what the sample test quesion was asking for. If it's asking which statements produce legal hashcodes, all of them do. If it's asking which produces the best hashcode, then I agree with (E), though I could also talk myself into (D).

My rule of thumb is that a hashcode should do a pretty good job of reflecting the uniqueness of an instance, by being a function of the instance's important state variables. What's that mean? It's open to debate, but the contract (see API page for Object.hashCode()) is that if a.equals(b) then a.hashCode() == b.hashCode().

The reason for all this is so that collections will work properly. Many collections (especially map implementations) use hashcodes to figure out how to store their contents. If a hashcode algorithm doesn't do a good job of distinguishing unequal objects (remember, unequal obs may have the same hashcode: it's just the reverse case that's forbidden) then collections perform inefficiently. On the other hand, if a hashCode() method always returns unequal hashcodes for unequal objects, that' not always ideal either. If the algorithm performs a ton of computation on the instance's state variables, then any collection that calls hashCode() will still run inefficiently.

So the point is to have a hashCode() method that strikes a good balance between distinction and performance.

What about the rule that only final variables should be part of the calculation? Well, if you stick to that you'll never get into a certain kind of trouble that's really hard to debug. If an object is stored in a collection, and that object's state changes in a way that affects hashCode() and/or equals(), really weird things can happen. So if the state is final, you can never experience those really weird things. However, I don't always make my state final, because sometimes I just can't. But when I have non-final state, I'm extra careful.

Hope this helps.

Consultant to SCJP team.<br />Co-designer of SCJD exam.<br />Co-author of "Complete Java 2 Certification Study Guide".<br />Author of "Ground-Up Java".
Shweta R Dhaneshwar
Ranch Hand

Joined: May 27, 2005
Posts: 35
Thanks a lot for explaining in detail.
I agree. Here's the link:
subject: hashCode() and equals()