hashCode() and equals()

[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.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.

class Test {
  int i1, i2;
  public void setI1(int i) {i1 = i;}
  public int getI1() {return i1;}
  public void setI2(int i) {i2 = i;}
  public int getI2() {return i2;}
  public Test(int ii1, int ii2) {i1 = ii1; i2 = ii2;}
  public boolean equals(Object obj) {
    if (obj instanceof Test) {
      return (i1 == ((Test)obj).getI1()) & (i2 == ((Test)obj).getI2());
    }
    return false;
  }
  public int hashCode() {
    // Insert statement here.
return 31 * getI1() + getI2();
}
 
public static void main(String args[])
{
Test t=new Test(1,2);
int initial=t.hashCode();
System.out.println(initial);
t.setI1(2);
t.setI1(4);
 
int later=t.hashCode();
System.out.println(later);
 

}
}
  

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

Thanks

[S Santhosh]

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]

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]

First glance to me suggests you have violated the fundametal rule, "never calculate the hashCode from non-final fields".

[Philip Heller]

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.

[Shweta R Dhaneshwar]

Thanks a lot for explaining in detail.
Regards,
Shweta