Today I was asked this question during an interview:
What will happen if we do not override the
hashcodemethod for our class, then add it to
HashTableand then try to get objects?
What could go wrong?
The idea with a
In general, you want to make sure of two things when implementing hash codes:
I would only add, that all of these concepts have to with identity and comparison.
There is a contract with hash code:
1.) 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.
2.) If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.
3.) It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.
The upshot is that if the hash codes are the same the entries in the table overwrite each other and that could be surprising to some...
Hope this helps.
It depends on what "adding to HashTable" means. Java's Hashtable doesn't have any
The interviewer probably meant that the key object's hashcode wouldn't be overridden. Only then the object identity issues, as pointed out in other answers, come into play. Even then, you don't necessarily have to override the key's hashcode. For example, if you use
If the question really was exactly what you wrote, I would have teased the interviewer with these questions. A good programmer doesn't assume that the interviewer probably meant this or that. He asks instead.
If the hashcode method is not overridden, the answer to this question really depends on if the same key object which was used to
a) If the same key object is used -
b) If some another "equivelent" key object is used - Since possibly the hashcode is going to be different due to default implementation of the hashcode method in
The answer is "nothing bad unless you have overridden
The general point is that if two objects compare equal i.e. if
then they must have the same hashcode i.e.
also if two objects have different hash codes, they must not compare equal.
This is especially relevant when you put objects in a hash table. This is because a hash table is an array of lists (called buckets usually). The hash bucket is indexed using the hash code, typically you use
So when you put an object in the hash table, you take the hash code of the key and use it to determine the bucket. You then put a key-value pair in the bucket. When you want to retrieve an object from the hash table, you take the hash code of the key to find the bucket and test the key of all the key-value pairs in the bucket with
So if you have two key objects which compare equal but have different hash codes and you use one as a key in a hash table, you won't be able to search for it using the other key object because you'll be looking in the wrong bucket.
The implementation of
you won't find your object if you get with a different object that is
or to give an example:
the reason for this is that HashTable (and HashMap) will use the hashcode to limit the space it has to search through to find the object and that relies on the assumption that if
Assuming your class extends only
This means that you will most likely not find the object again in the Map (you might find it by chance, however).
The answer is: similar objects (all fields having equal values) would not create the same hash code, so you would need exactly the same (identical) object that was used for