CODEWITHSUNDEEP
javascjp
dierre
dierre

Reputation: 7220

How is the proper usage of the hashcode method?

I'm preparing for the java certification, apparently I could not answer correctly to this answer.

Given:

2. class Chilis {
3.     Chilis(String c, int h) { color = c; hotness = h; }
4.     String color;
5.     private int hotness;
6.     public boolean equals(Object o) {
7.         Chilis c = (Chilis)o;
8.         if(color.equals(c.color) && (hotness == c.hotness)) return true;
9.         return false;
10.     }
11.   // insert code here
12. }

Which, inserted independently at line 11, fulfill the equals() and hashCode() contract for Chilis? (Choose all that apply.)

  • A. public int hashCode() { return 7; }
  • B. public int hashCode() { return hotness; }
  • C. public int hashCode() { return color.length(); }
  • D. public int hashCode() { return (int)(Math.random() * 200); }
  • E. public int hashCode() { return (color.length() + hotness); }

The book says: 

A, B, C, and E are correct. They all guarantee that two objects that equals() says are
equal, will return the same integer from hashCode(). The fact that hotness is private
has no bearing on the legality or effectiveness of the hashCode() method.

Now I got right A and B but not C and E because it doesn't sound correct to me. Look at the following example:

Under c = new Under("ciao", 9);
Map<Under, String> map = new HashMap<Under, String>();

map.put(c, "ciao");
System.out.println(map.get(c));
c.color = "uauauauauau";

System.out.println(map.get(c));

And the output will be:

ciao
null

And I said that based on the access modifier of color. On the documentation of the Object class we have the contract:

So according to the first of these rules, should it be expected to have this behavior?

Upvotes: 1

Views: 177

Answers (3)

OnlyThenDidIReckonMyCurse
OnlyThenDidIReckonMyCurse

Reputation: 559

From the documentation you cited:

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.

So this is expected behavior. If equals and hashCode use mutable fields and you put the affected object in a HashMap and the values change, then all bets are off.

Upvotes: 4

Ingo
Ingo

Reputation: 36339

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified.

This is another way to say that if infoirmation used in equals comparisons is changed, then the hascode may be different. This is what happens in C and E.

Upvotes: 2

Jakub Kubrynski
Jakub Kubrynski

Reputation: 14159

Normally hashCode should not change during object lifetime, so it should use final fields. Since color can be changed during execution it should't be used in hashcode or equals

Upvotes: 2

Related Questions