HashCode Call

[mash john]

I would like to know whether the hashCode method will be called when we invoke equals method.Because they say if two objects are equal using the equals method,they should have equal hashcodes.Please clarify my query.
[ September 05, 2005: Message edited by: Michael Ernest ]

[Ulf Dittmer]

To help you answer that question you could either study the source code of java.lang.Object, or write a class that overrides hashCode.

[mash john]

I tried overriding the hashCode and equals methods in a class.But when equals method is called ,the hashCode method is not getting invoked.Why is this happening?

[David O'Meara]

What you quoted was a statement of intent, not a statement of fact. Or to paraphrase myself, they are hinting that you should always override hashCode when you override equals. Otherwise you could define an equals contract that returns different hashCode values and things would just start breaking and you may never know why...

[Layne Lund]

Originally posted by David O'Meara:
What you quoted was a statement of intent, not a statement of fact. Or to paraphrase myself, they are hinting that you should always override hashCode when you override equals. Otherwise you could define an equals contract that returns different hashCode values and things would just start breaking and you may never know why...

In particular, many classes from the Collections framework will break. This is the main intent of this particular contract, from what I understand. In particular, HashMap() and HashSet() use the hashCode() method, so if you don't conform to the contract between hashCode() and equals(), these two collections may have odd behaviors.

In general, the equals() method does NOT call the hashcode() method. Although, you COULD write it this way if you want. However, notice that it isn't necessary to fulfill the contract. In fact, it might not be a good idea since the contract only specifies one direction: if a.equals(b) returns true, then a.hashcode() should equal b.hashcode(). It is quite possible to write a hashcode() method that returns equal values for two objects such that the equals() method still returns false. This doesn't break the contract.

Layne

[Tony Morris]

Originally posted by mash john:
I tried overriding the hashCode and equals methods in a class.But when equals method is called ,the hashCode method is not getting invoked.Why is this happening?

Is this because you expect that two objects with equal hash codes implies that the two objects are also equal? Are you aware that this is impossible to achieve (unless you control construction, thus not violating encapsulation, which you should always do anyway). All it takes is 2^32+1 unequal objects and you have a guaranteed hash code collision. In practice, collisions occur all the time.

I suggest reading up on the contracts in java.lang.Object.
Also
http://www.jtiger.org/javadoc/org/jtiger/assertion/EqualsMethodContract.html
http://www.jtiger.org/javadoc/org/jtiger/assertion/HashCodeMethodContract.html

[Norm Radder]

hashcodes are used for Hashtables. They are a way to allocate an object to one of n buckets/lists in a hashtable.

A simple example: you have 10000 items with associated keys that are to be stored for quick and easy retrieval.
To have an efficient lookup method you would like to take the key and use it to access the associated data with the fewest compares. One way is a hashtable. You allocate a number of lists(buckets) to hold keys with the same hashcode. You create a hashcode that returns values from o to the number of lists and then use that hashcode as an index into the lists array.
Then the seach routine searches that list for the desired key.
The problem is creating a hashcode that will map all the data evenly over the number of lists. For our example of 10000 items, say we want to have 100 lists, the best hashcode function would map all the keys to 100 items in each list. That would be perfect.

Because of Hashtable lookup uses equals() the hashcode for equal objects must be the same. Otherwise the objects could be in separate lists/buckets.