Categories
equals hashcode java

Why do I need to override the equals and hashCode methods in Java?

494

Recently I read through this
Developer Works Document.

The document is all about defining hashCode() and equals() effectively and correctly, however I am not able to figure out why we need to override these two methods.

How can I take the decision to implement these methods efficiently?

2

  • 1

    Case Override only equals: two same object will have different hashcode = same objects go in different bucket(duplication). Case Override only hashcode:two same object will have same hashcode = same object go in same bucket(duplication).

    – VeKe

    Sep 12, 2017 at 9:27


  • The link appears to be dead. Can I obtain the IBM’s developer works document?

    Jun 18, 2021 at 8:42

655

Joshua Bloch says on Effective Java

You must override hashCode() in every class that overrides equals(). Failure to do so will result in a violation of the general contract for Object.hashCode(), which will prevent your class from functioning properly in conjunction with all hash-based collections, including HashMap, HashSet, and Hashtable.

Let’s try to understand it with an example of what would happen if we override equals() without overriding hashCode() and attempt to use a Map.

Say we have a class like this and that two objects of MyClass are equal if their importantField is equal (with hashCode() and equals() generated by eclipse)

public class MyClass {
    private final String importantField;
    private final String anotherField;

    public MyClass(final String equalField, final String anotherField) {
        this.importantField = equalField;
        this.anotherField = anotherField;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result
                + ((importantField == null) ? 0 : importantField.hashCode());
        return result;
    }

    @Override
    public boolean equals(final Object obj) {
        if (this == obj)
            return true;
        if (obj == null)
            return false;
        if (getClass() != obj.getClass())
            return false;
        final MyClass other = (MyClass) obj;
        if (importantField == null) {
            if (other.importantField != null)
                return false;
        } else if (!importantField.equals(other.importantField))
            return false;
        return true;
    }
}

Imagine you have this

MyClass first = new MyClass("a","first");
MyClass second = new MyClass("a","second");

Override only equals

If only equals is overriden, then when you call myMap.put(first,someValue) first will hash to some bucket and when you call myMap.put(second,someOtherValue) it will hash to some other bucket (as they have a different hashCode). So, although they are equal, as they don’t hash to the same bucket, the map can’t realize it and both of them stay in the map.


Although it is not necessary to override equals() if we override hashCode(), let’s see what would happen in this particular case where we know that two objects of MyClass are equal if their importantField is equal but we do not override equals().

Override only hashCode

If you only override hashCode then when you call myMap.put(first,someValue) it takes first, calculates its hashCode and stores it in a given bucket. Then when you call myMap.put(second,someOtherValue) it should replace first with second as per the Map Documentation because they are equal (according to the business requirement).

But the problem is that equals was not redefined, so when the map hashes second and iterates through the bucket looking if there is an object k such that second.equals(k) is true it won’t find any as second.equals(first) will be false.

Hope it was clear

21

  • 6

    can you please elaborate a little more , in second case , why the second object must go in another bucket?

    May 5, 2014 at 23:31

  • 80

    I don’t like this answer because it suggests that you can’t override hashCode() without overriding equals(), which is simply not true. You say your example code (the “override only hashCode” part) won’t work because you define your two objects as equal, but – sorry – this definition is only in your head. In your first example you have two un-equal objects with the same hashCode, and that is perfectly legal. So the reason you need to override equals() is not because you have already overridden hashCode(), but because you want to move your “equals” definition from your head to the code.

    Dec 30, 2014 at 15:38


  • 20

    if you think you need to override one, then you need to override both of them is wrong. You need to override hashCode if your class overrides equals but reverse is not true.

    Oct 17, 2015 at 9:00

  • 8

    I think it’s totally ok to override only hashCode() without overriding equals() as well. It’s also whats written in Effective Java: books.google.fr/…

    – Johnny

    Apr 4, 2016 at 12:59


  • 3

    @PhantomReference, note that only overriding equals would violate the contract spelled out in the javadoc of Object: “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.” Sure, not all parts of all contracts are exercised in all code, but still, formally speaking it’s a violation and I’d consider it to be a bug waiting to happen.

    – aioobe

    Nov 27, 2016 at 10:20

352

Collections such as HashMap and HashSet use a hashcode value of an object to determine how it should be stored inside a collection, and the hashcode is used again in order to locate the object
in its collection.

Hashing retrieval is a two-step process:

  1. Find the right bucket (using hashCode())
  2. Search the bucket for the right element (using equals() )

Here is a small example on why we should overrride equals() and hashcode().

Consider an Employee class which has two fields: age and name.

public class Employee {

    String name;
    int age;

    public Employee(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    @Override
    public boolean equals(Object obj) {
        if (obj == this)
            return true;
        if (!(obj instanceof Employee))
            return false;
        Employee employee = (Employee) obj;
        return employee.getAge() == this.getAge()
                && employee.getName() == this.getName();
    }

    // commented    
    /*  @Override
        public int hashCode() {
            int result=17;
            result=31*result+age;
            result=31*result+(name!=null ? name.hashCode():0);
            return result;
        }
     */
}

Now create a class, insert Employee object into a HashSet and test whether that object is present or not.

public class ClientTest {
    public static void main(String[] args) {
        Employee employee = new Employee("rajeev", 24);
        Employee employee1 = new Employee("rajeev", 25);
        Employee employee2 = new Employee("rajeev", 24);

        HashSet<Employee> employees = new HashSet<Employee>();
        employees.add(employee);
        System.out.println(employees.contains(employee2));
        System.out.println("employee.hashCode():  " + employee.hashCode()
        + "  employee2.hashCode():" + employee2.hashCode());
    }
}

It will print the following:

false
employee.hashCode():  321755204  employee2.hashCode():375890482

Now uncomment hashcode() method , execute the same and the output would be:

true
employee.hashCode():  -938387308  employee2.hashCode():-938387308

Now can you see why if two objects are considered equal, their hashcodes must
also be equal? Otherwise, you’d never be able to find the object since the default
hashcode method in class Object virtually always comes up with a unique number
for each object, even if the equals() method is overridden in such a way that two
or more objects are considered equal. It doesn’t matter how equal the objects are if
their hashcodes don’t reflect that. So one more time: If two objects are equal, their
hashcodes must be equal as well.

7

  • @rajeev I have one confusion, why do we need to override equals method when we override hashCode method in case of HashMap? In any case, hashmap replaces the value if object’s hashcode is equal.

    Mar 13, 2017 at 8:42

  • 5

    @VikasVerma equals object will have equal hashcode doesn’t mean unequal object will have unequal hashcode. What if objects are actually different, but their hashcode is same ?

    – Ravi

    Dec 12, 2017 at 6:21


  • 1

    Any reason to use those numbers (17 & 31) in hashcode() implementation to generate the hashcode? Can we use any random numbers?

    – JavaYouth

    Jan 29, 2019 at 7:19


  • 1

    @JavaYouth Yes, you can

    Jan 29, 2019 at 13:40

  • 2

    @JavaYouth , as mentioned by Rajeev, you can use any other values. However, it is suggested to use prime numbers as this will produce less collisions.

    – Darwin

    Dec 29, 2021 at 8:30

54

You must override hashCode() in every
class that overrides equals(). Failure
to do so will result in a violation of
the general contract for
Object.hashCode(), which will prevent
your class from functioning properly
in conjunction with all hash-based
collections, including HashMap,
HashSet, and Hashtable.

   from Effective Java, by Joshua Bloch

By defining equals() and hashCode() consistently, you can improve the usability of your classes as keys in hash-based collections. As the API doc for hashCode explains: “This method is supported for the benefit of hashtables such as those provided by java.util.Hashtable.”

The best answer to your question about how to implement these methods efficiently is suggesting you to read Chapter 3 of Effective Java.

6

  • 5

    This the correct answer. To corollary being, of course, that if you never use the class in a hash-based collection, then it doesn’t matter that you haven’t implemented hashCode().

    – slim

    Oct 15, 2015 at 15:36

  • 2

    In a more complex cases, you never know if the collections you use are using hashes, so stay away from “it doesn’t matter that you haven’t implemented hashCode()”

    Mar 19, 2016 at 20:47

  • 1

    Can I override hashCode() without overriding equals()?

    – Johnny

    Apr 4, 2016 at 13:45

  • @Johnny certainly you can override the hascode without override the equals. But what would be the use case?

    – Gi1ber7

    Mar 12, 2021 at 14:28

  • @Gi1ber7 check my answer a little under from here to understand analytically what is happening with HashMap and HashTable for equals and hashCode

    Oct 5, 2021 at 23:12