• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Problem with mock exam question

 
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is from the John Meyer's SCJP 5.0 Quiz:



I know the test is right but this is really confusing to me. I thought that there was an "equals" contract that said for two objects to be equal the hashCode HAD to be equal. They obviously do not have to be since this self compiled output shows "true".

Did I miss a fine point ... like.... that it is up to the equals method implementation to DO the hashCode comparison???
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
but aren't you overriding the equals method?
 
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In the class above the equals() method has been overridden to make two objects of the same class to be considered meaningfully equal. The hashcode() method has Not been overridden, thats perfectly legal....The hashcode() method matters only if you want to put these objects of these classes into a collection and want to retrieve them...

Lets say for example

You have a HashMap collection in which you want to put objects of type TestTwelve(the above mentioned class)..here is the code

HashMap h=new HashMap();
h.put(new TestTwelve(3),new TestTwelve(5));//1
h.put(new TestTwelve(5),new TestTwelve(6));//2
//You try to retrieve the above objects as below
h.get(new TestTwelve(3));
h.get(new TestTwelve(5));

But the result will be rubbish since you cannot retrieve the objects which you inserted on lines1 and 2

So the thing is hashcode() and equals() must be overridden only if you are using your class as a key in a hashmap or any other collection class that uses hashcodes.

The code above is just comparing the two objects and saying its equal.It has nothing to do with collection classes... The other thing in the code is the 2 hashcode values returned are different and so these two objects land in different buckets(when collection is involved)

The contracts matter if collections are involved

[ August 21, 2008: Message edited by: Thirumalai Muthu ]
[ August 21, 2008: Message edited by: Thirumalai Muthu ]
 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Usually two different objects would not be equal when their hash code is different.

But the equal method is overwritten in you code. Here two objects of type TestTwelve are equal exacly when their x member variable are equal.

You gave all of your x member variables the same value which is 3.

Therefore your overloaded equals method gave true as result.
 
Bob Ruth
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oooooooookay!!!
So, putting together what I seem to be seeing, if I override equals() then it is up to my overriding method to do the hashCode comparison...BUT... if I don't DO a hashCode comparison then the implementation of the equals() method absolutely controls the determination of equivalence?

I know this sounds basic, but I just had that "equals contract" burned into my head somewhere and it LOOKS like it is up to your equals() implementation to enforce that contract. If you choose to make a super-simple determination of equivalence... then it can be anything you want it to be without regard to the hashCode. So, in a sense, the equals() in this override is not enforcing the "equals contract" but that does NOT stop it from declaring two objects "equal" if it wants to?? That is the way it looks to me...
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


equals() method absolutely controls the determination of equivalence?



equals method always control the equivalence between two objects idenpedent of what the hashcode do, but remember a map use an int ( hashCode in this case)
to index their elements because of performance reasons..so a map needs a way to identify each object.. and the a hashcode is the solution, so if you do not overwrite your hashCode JVM will give a random and unique hascode for each object..
and so if you have two equals() object you probably would like to use the same one with 2 references right? if you do, you will follow the contract and overwrite the hashCode.
[ August 22, 2008: Message edited by: willy kocher ]
 
Bob Ruth
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There you go! Thanks Willy, THAT was the "knot" that I was looking for.
It makes sense now... thanks!

Bob
 
Climb the rope! CLIMB THE ROPE! You too tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic