Paari Lenin

Greenhorn
+ Follow
since Sep 01, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Paari Lenin

hi, Burkhard Hassel

Can you please clarify whether default hashcode() returns unique value for each object or is there a possibility for the default hashcode() to give duplicate values. I am confused now...
Did any of the above explanations made you think otherwise that hashCode doesn't generate a unique code everytime.
Hi,

Nice to know that somebody takes the effort to clarify others doubts spending their precious time.

Thanks to Chandra Kota and Burkhard Hassel.


I think, now I have got it right. (corrections always welcome)

Reason 1:
As Burkhard Hassel said, we don�t want SETs to have meaningfully equal objects stored in our collection just because default hashCode says they are different objects.

Reason 2:

We use collections to store data and on a later date retrieve it back.

When (I don't override hashCode()) I store an element in a collection that uses hashing it will generate a unique hash and puts it in relevant bucket. Then when I want to retrieve it back I need to give something and whatever I give as my search criteria, the first thing the collection will do is take the newly generated hashCode(default) (not same as before and go to a different bucket) and then it will search for my object. It will not be found as the hashCode will be different for two different runs for the same object.

If I have overriden the hashCode based on data that is relavant or unique to the object, for different runs then it would still generate the same hashCode.

So it is mandatory to override hashCode for collections that use hashing.

Now after coming to the bucket there may be different objects with the same hashCode. Now to sort the exact match we cannot go with the default which also checks based on reference value. So we have to override the equals method also mandatorily.

Reason 3:

Another reason for maintaining the contract I believe is that, the default hashCode and equal method that comes with the API will be true for two equal objects which must not be changed when we override it in our programs.

Reason 4:
I have stored one object in collection. And in order to retrieve it (during the same execution) I am passing a meaningfully equal object (just as I have overriden my equals method to consider two objects to be equal). Now if I have not followed the contract my hashcode will be different for these two meaningfully equal object. So I will not have a successful search in collections that use hashing.

Rgds,

Paari.
Hi,

Can somebody provide some material to understand collections and generics better. Thanks.
Hi,

I have a doubt about overriding hashcode() and equals().

I understand the need to override hashcode() separately and equals() separately.


But I don't understand the contract that if i override equals() i should also override hashcode(). I understand it like if I don't maintain the contract then I will have a performance hit( or the purpose of hashing becomes useless) but how is that that I wont be able to find the element put into the hashtable if I don't override hashcode() method also.

Can somebody explain me please ?

I am going through Kathy sierra book and I am bit confused about this?