However, let's say I have 2 Student objects with equal content (Same social security number).
I add them into the hashMap.
2 Student objects may produce different hashodes too! That's possible. Right?
And these 2 object's content are equal (Same social security number). So in the hashtable we have memory leak. We have 2 different hashcodes located at different bucket on hashtable but at the same time these 2 Student objects have the same content.
If both students are "equal" then the MUST return the same hash code and so you only have, really, one student, and one would over write the other in the HashTable. If they don't return the same hash code then that's a bug and good luck with your bug hunt.
If you are only using the SSN field to test for equality then you should only use the SSN field to generate the hash code.
Note that SSNs are supposed to be unique but are not guaranteed to be unique. Additionally, I believe there's fine print in the laws forbidding anyone other than the government from using an SSN as an ID (though for years that was ignored). You'll see most all places today will assign a person an ID specific to that corporation or entity. Places, such as banks, that have to report your activities to the IRS still require your SSN.
Yes, it is possible to write buggy code. In the video he says that if that happens it is because the code violates the equals/hashCode "contract". And it will cause problems with the business logic, as he states.
So this is my summary. Please correct me if I am wrong.
Using HashSet and HashMap:
I have to override hashCode() and equals() methods and write out the logic for both methods.
Java calls hashCode() first. Checks hashtable. If hashtable has the same hashcode, it calls equals().
Java doesn't call compareTo() because HashSet and HashMap are not sorted collections.
Using TreeSet and TreeMap:
They are sorted collections. So I have to implement Comparable interface and override compareTo() method.
Java doesn't call hashCode() because they don't use hashtable.
Java doesn't call equals(). Why?
You have only scratched the surface. Read the following resources about hashCode() and equals():-
1: Effective Java by Joshua Bloch.
2: Search for Angelika Langer equals Java hashCode and make sure to get the English version, not German.
3: Search for artima.com Odersky Spoon and Venners equals (the same link is in our FAQ).
There are eight things you have to ensure if you are to write a correct equals() method. Also, as you have been told, you have to be careful to ensure that two objects returning true from equals() will have the same hash code.
Don't say that Java® calls any methods. It is part of the hash map implementation that calls the methods.
The video you linked to is quite good, but there were two things I disagree with:-
1: He showed a 9‑bucket Map. The hash map implementation has its bucket count always as a power of 2.
2: He suggested that a hash map can degenerate to run in quadratic time; I think it will run in linear time at worst. But linear time in a large hash map can be too slow for the application to work.
You must ensure that the comparisons used for a tree set and similar are “consistent with equals()”. More information in the Comparable interface.
For TreeSet and TreeMap Java calls compareTo() instead of equals(). compareTo() is a superset of equals(). If compareTo() is written correctly then equals() could be implemented as:
Note that you'd have to make sure that compareTo() doesn't violate the equals/hashCode contract as well.