Hashing Equals only returns true - collections

Question

Consider the sample code:
class EmployeeClass {
int id;
public EmployeeClass(int eid) {
this.id=eid;
}
#Override
public int hashCode(){
return this.id;
}
#Override
public boolean equals(Object o){
return true;
}
}
public class HashcodeAndEquals {
public static void main(String[] args) {
Map map=new HashMap();
EmployeeClass e1=new EmployeeClass(1);
map.put(e1, "Employee 1"); // line 1
EmployeeClass e2=new EmployeeClass(2);
map.put(e2, "Employee 2");
EmployeeClass e3=new EmployeeClass(3);
EmployeeClass e4=new EmployeeClass(1); // line 2
EmployeeClass e5=new EmployeeClass(1);
map.put(e5, "Employee 5"); // line 3
System.out.println("e1 -> "+map.get(e1));
System.out.println("e2 -> "+map.get(e2));
System.out.println("e3 -> "+map.get(e3));
System.out.println("e4 -> "+map.get(e4)); // line 4
System.out.println("e5 -> "+map.get(e5));
}
}
Output:
e1 -> Employee 5
e2 -> Employee 2
e3 -> null
e4 -> Employee 5
e5 -> Employee 5
After line 1 runs, then line 3 override the value of e1 but my equals method return true only. Also at line 4 we get the value of e4 even though equals method only return true. Since equals method has no comparison only returns true, how put and get is working here. What is happening behind the scenes?

Answer 1

I'm guessing you're surprised that not all of them are Employee 5? Equals always returns true so e5 should have overwritten all of them, right?
A HashMap uses "buckets" behind the scenes. Let's say that there's only 2, to make it simple. A real HashMap has a lot more.
When you put an object into a HashMap, it looks at the hashCode first. (That's why it's called a HashMap.) Based on the hashCode, it chooses a bucket to store it in. For e1, the hashCode is 1, so it would choose bucket 1. For e2, it's 2, so that goes into bucket 2. The hashCode for e3 is 3, but there's only 2 buckets, so it will go into bucket 3 modulo 2, which is 1. e4 goes into bucket 2 for the same reason, and e5 is back in 1.
Note that I'm simplifying here extremely; in reality the process is a little more complex, but this should be enough to explain things.
So we have the following buckets:
bucket 1 | bucket 2
e5 | e4
e3 | e2
e1 |
So now it's time to retrieve values. When I retrieve e1, the hashCode is still 1, so it looks in bucket 1. There, it picks the first object which equals e1, which is e5: the last object you put in, is the first that gets out, apparently. e2 directs to bucket 2, so in this example case, you would get e4 as a result.
In your case, you did never actually put e3 and e4 into the HashMap. But because e3's hashCode directs to bucket 1, and it's equal to e5, when you look up e3 you still get e5 even though it's not actually there.
As I said, this is an extreme simplification of things. In a real HashMap, there's a lot more than 2 buckets. So in your case, e3 has a hashcode that directs to an empty bucket, and the hashCodes for e1, e4 and e5 apparently all direct to the same bucket.
This is why it's important, when you write hashCode, to give it a good "distribution". If you always return 42, all objects would always go into the same bucket, which would turn your HashMap into essentially a very awkward ArrayList. You'd lose al the performance benefits that HashMap gives you.