This is my summary after reading a wonderful article from ibm (Java theory and practice: Hashing it out.

In my understanding, every object in Java has two implemented methods hashCode() and equals() to identify each object to others. A general rule is that two objects are equal to each other, they have the same hashcode (but the reverse is may not be true – and it is called collision).

Generally, we want to override both of them because of their relationship as mentioned above.

There are some requirements when you override two methods:

For equals(), it should:

Symmetry: a.equals(b) == b.equals(a)

Transitivity: a.equals(a) = true;

Reflexivity:  a.equals(b) == true, b.equals(c) == true -> c.equals(a) == true;

For hashCode():

Consistency: if a.equals(b) == true then a.hashCode() == b.hashCode()

Normally, when you implement the hashCode() method, we should not change the object’s hashCode() on the fly. Especially when we use a collection of objects, theirs hashCode should stay the same to avoid some unpredictable result. And we can refer these such objects as immutable objects – which their states do not change after it is constructed.
Finally, here are the interface for both two methods:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public boolean equals(Object object){
 
if (this == object) return true;
 
if (!this.getClass().equals(object.getClass())  return false;
 
return sth;
 
}
 
public int hashCode(){
 
return sth;
 
}