Doubt on PRACTICE EXAMS - OCP JAVA By kathy sierra and barty bates book about equals and hashcode

[Jeane Lindford]

the question on page 101/102:

2. class Chilis {
3.    Chilis(String c, int h) { color = c; hotness = h; }
4.    String color;
5.    int hotness;
6.    public boolean equals(Object o) {
7.       if(this == (Chilis)o) return true;
8.       return false;
9.    }
10.  public String toString() { return color + " " + hotness; }
11. }

If instances of class Chilis are to be used as keys in a Map, which are true? (Choose all that
apply.)

A. Without overriding hashCode(), the code will not compile.
B. As it stands, the equals() method has been legally overridden.
C. It’s possible for such keys to find the correct entries in the Map.
D. It’s NOT possible for such keys to find the correct entries in the Map.
E. As it stands, the Chilis class legally supports the equals() and hashCode() contracts.
F. If hashCode() was correctly overridden, it would make retrieving Map entries by key easier.

The correction from the book:

 B, C, and E are correct. If a class does NOT override equals() and hashCode(), class
Object provides a default implementation. The default implementation’s logic is that only
two references to THE SAME OBJECT will be considered equal.
Given that, it might appear that equals() has been overridden, but in practice this
overridden equals() method performs exactly as the default method performs. Therefore,
the equals() and hashCode() methods will support their contracts, although it will be
hard for a programmer to use this class for keys in a Map.
 A is incorrect because the code compiles. D is incorrect based on the above. F is incorrect
because in practice equals() hasn’t really been overridden.

I disagree with:

C - if hashCode is not overriden, every Chilis will be placed in a distinct bucket, and so, even if the equals is overriden correctly, you will not be able to find that object again without know the correct bucket number (only if you still have a reference variable that you used to put that Chilis in the map,... ok.. this makes C ok , but, if I assume that a chilis will be putted like "map.put(new Chilis(arg1, arg2))"?)

F - the quote " it would make retrieving Map entries by key easier" makes you think about an easy and simple modification on equals.. if the hashcode was correctly overriden, with a simple and easy modification on equals would make the code fine

this question is so abstract to me..

[Harnoor Singh]

I think point C is correct. We have neither modified the equals() nor hashcode() method. So it can find the correct entry from map.

[Ikpefua Jacob-Obinyan]

Hello Jeane...Abstract questions are meant to toughen you up in your preparations for the exams, because some of the hardest questions use semantic nuances to frustrate you
When answering questions in the real exams you MUST analyse a code as-is-stands...(options B & E begins with as-it-stands...thats a clue) I mean what you see with your eyes. If you take a second look at the program you will notice that there was NO hashCode() override in the first place Talkless of whether it is correctly overridden or not, that makes option 'F' a "non-starter"...Did you get the catch?
Option 'E' is quite trickish though because its testing your knowledge on differentiating "legal" and "appropriate"... Option 'B' did something similar.

Regards

Ikpefua

[Jeane Lindford]

Harnoor Singh wrote:I think point C is correct. We have neither modified the equals() nor hashcode() method. So it can find the correct entry from map.

only with a reference variable used to put the item on the map, i`m right? otherwise, no way to find it

[Harnoor Singh]

Jeane Lindford wrote:

Harnoor Singh wrote:I think point C is correct. We have neither modified the equals() nor hashcode() method. So it can find the correct entry from map.

only with a reference variable used to put the item on the map, i`m right? otherwise, no way to find it

Reference variable will not play any part. The key will be converted into hashcode and that hascode will be used to access the value from bucket/array.

[Piyush Joshi]

Harnoor Singh wrote:
Reference variable will not play any part. The key will be converted into hashcode and that hascode will be used to access the value from bucket/array.

I think thats not correct.

Hashcode is used to group the keys in buckets, that is one bucket for one hashcode, to make the access faster. Inside one bucket you can have many number of different keys having same hashcode.

If you try to find a key in a hashmap then first it will get the hashcode of the given object to find the right bucket. But inside that bucket you can have many keys. To find the correct key it then uses the equals() method to compare each key in bucket with the given object.

So if you override the equals method in a way as in the given example, then to find the key, you need the reference to the original object you used to put the key in.

[Jeane Lindford]

Piyush Joshi wrote:
If you try to find a key in a hashmap then first it will get the hashcode of the given object to find the right bucket. But inside that bucket you can have many keys. To find the correct key it then uses the equals() method to compare each key in bucket with the given object.

So if you override the equals method in a way as in the given example, then to find the key, you need the reference to the original object you used to put the key in.

yeah... I think you're right Piyush Joshi
with no override of hashCode(), how do the programmer find that bucket again, since the Object's hashCode() is a native implementation that returns a new value for every new created Object (or Chilis in this case)?

for example:

someMap.put(new Chilis("hi", 1), "theValue");

how find Chilis("hi", 1) on the Map? no way to find it (maybe only iterating over the map entries I think)
and with no "meaningful" implementation of equals() the same happens..

[Piyush Joshi]

you got it