equals hashcode java overriding

What issues should be considered when overriding equals and hashCode in Java?


What issues / pitfalls must be considered when overriding equals and hashCode?


    The theory (for the language lawyers and the mathematically inclined):

    equals() (javadoc) must define an equivalence relation (it must be reflexive, symmetric, and transitive). In addition, it must be consistent (if the objects are not modified, then it must keep returning the same value). Furthermore, o.equals(null) must always return false.

    hashCode() (javadoc) must also be consistent (if the object is not modified in terms of equals(), it must keep returning the same value).

    The relation between the two methods is:

    Whenever a.equals(b), then a.hashCode() must be same as b.hashCode().

    In practice:

    If you override one, then you should override the other.

    Use the same set of fields that you use to compute equals() to compute hashCode().

    Use the excellent helper classes EqualsBuilder and HashCodeBuilder from the Apache Commons Lang library. An example:

    public class Person {
        private String name;
        private int age;
        // ...
        public int hashCode() {
            return new HashCodeBuilder(17, 31). // two randomly chosen prime numbers
                // if deriving: appendSuper(super.hashCode()).
        public boolean equals(Object obj) {
           if (!(obj instanceof Person))
                return false;
            if (obj == this)
                return true;
            Person rhs = (Person) obj;
            return new EqualsBuilder().
                // if deriving: appendSuper(super.equals(obj)).
                append(age, rhs.age).

    Also remember:

    When using a hash-based Collection or Map such as HashSet, LinkedHashSet, HashMap, Hashtable, or WeakHashMap, make sure that the hashCode() of the key objects that you put into the collection never changes while the object is in the collection. The bulletproof way to ensure this is to make your keys immutable, which has also other benefits.


    • 13

      Additional point about appendSuper(): you should use it in hashCode() and equals() if and only if you want to inherit the equality behavior of the superclass. For instance, if you derive straight from Object, there’s no point because all Objects are distinct by default.

      May 28, 2009 at 19:03

    • 317

      You can get Eclipse to generate the two methods for you: Source > Generate hashCode() and equals().

      Nov 22, 2011 at 18:58

    • 28

      Same is true with Netbeans:…

      – seinecle

      Aug 11, 2012 at 7:59

    • 6

      @Darthenius Eclipse generated equals uses getClass() which might cause problems in some cases (see Effective Java item 8)

      Dec 8, 2013 at 18:46

    • 7

      The first null check is not necessary given the fact that instanceof returns false if its first operand is null (Effective Java again).

      – izaban

      Dec 13, 2013 at 19:51


    There are some issues worth noticing if you’re dealing with classes that are persisted using an Object-Relationship Mapper (ORM) like Hibernate, if you didn’t think this was unreasonably complicated already!

    Lazy loaded objects are subclasses

    If your objects are persisted using an ORM, in many cases you will be dealing with dynamic proxies to avoid loading object too early from the data store. These proxies are implemented as subclasses of your own class. This means thatthis.getClass() == o.getClass() will return false. For example:

    Person saved = new Person("John Doe");
    Long key =;
    Person retrieved = dao.retrieve(key);
    saved.getClass().equals(retrieved.getClass()); // Will return false if Person is loaded lazy

    If you’re dealing with an ORM, using o instanceof Person is the only thing that will behave correctly.

    Lazy loaded objects have null-fields

    ORMs usually use the getters to force loading of lazy loaded objects. This means that will be null if person is lazy loaded, even if person.getName() forces loading and returns “John Doe”. In my experience, this crops up more often in hashCode() and equals().

    If you’re dealing with an ORM, make sure to always use getters, and never field references in hashCode() and equals().

    Saving an object will change its state

    Persistent objects often use a id field to hold the key of the object. This field will be automatically updated when an object is first saved. Don’t use an id field in hashCode(). But you can use it in equals().

    A pattern I often use is

    if (this.getId() == null) {
        return this == other;
    else {
        return this.getId().equals(other.getId());

    But: you cannot include getId() in hashCode(). If you do, when an object is persisted, its hashCode changes. If the object is in a HashSet, you’ll “never” find it again.

    In my Person example, I probably would use getName() for hashCode and getId() plus getName() (just for paranoia) for equals(). It’s okay if there are some risk of “collisions” for hashCode(), but never okay for equals().

    hashCode() should use the non-changing subset of properties from equals()


    • 2

      @Johannes Brodwall: i don’t understand Saving an object will change it's state! hashCode must return int, so how will you use getName()? Can you give an example for your hashCode

      Nov 1, 2012 at 14:14

    • @jimmybondy: getName will return a String object which also has a hashCode which can be used

      Mar 2, 2013 at 13:15


    A clarification about the obj.getClass() != getClass().

    This statement is the result of equals() being inheritance unfriendly. The JLS (Java language specification) specifies that if A.equals(B) == true then B.equals(A) must also return true. If you omit that statement inheriting classes that override equals() (and change its behavior) will break this specification.

    Consider the following example of what happens when the statement is omitted:

        class A {
          int field1;
          A(int field1) {
            this.field1 = field1;
          public boolean equals(Object other) {
            return (other != null && other instanceof A && ((A) other).field1 == field1);
        class B extends A {
            int field2;
            B(int field1, int field2) {
                this.field2 = field2;
            public boolean equals(Object other) {
                return (other != null && other instanceof B && ((B)other).field2 == field2 && super.equals(other));

    Doing new A(1).equals(new A(1)) Also, new B(1,1).equals(new B(1,1)) result give out true, as it should.

    This looks all very good, but look what happens if we try to use both classes:

    A a = new A(1);
    B b = new B(1,1);
    a.equals(b) == true;
    b.equals(a) == false;

    Obviously, this is wrong.

    If you want to ensure the symmetric condition. a=b if b=a and the Liskov substitution principle call super.equals(other) not only in the case of B instance, but check after for A instance:

    if (other instanceof B )
       return (other != null && ((B)other).field2 == field2 && super.equals(other)); 
    if (other instanceof A) return super.equals(other); 
       else return false;

    Which will output:

    a.equals(b) == true;
    b.equals(a) == true;

    Where, if a is not a reference of B, then it might be a be a reference of class A (because you extend it), in this case you call super.equals() too.


    • 2

      You can make equals symmetric this way (if comparing a superclass object with subclass object, always use the equals of the subclass) if (obj.getClass() != this.getClass() && obj.getClass().isInstance(this)) return obj.equals(this);

      – pihentagy

      Feb 25, 2010 at 10:40

    • 6

      @pihentagy – then I’d get a stackoverflow when the implementation class doesn’t override the equals method. not fun.

      – Ran Biron

      Dec 6, 2010 at 19:16

    • 2

      You won’t get a stackoverflow. If the equals method is not overridden, you will call the same code again, but the condition for recursion will always be false!

      Aug 4, 2013 at 12:32

    • 1

      @pihentagy: How does that behave if there are two different derived classes? If a ThingWithOptionSetA can be equal to a Thing provided that all the extra options have default values, and likewise for a ThingWithOptionSetB, then it should be possible for a ThingWithOptionSetA to be compare equal to a ThingWithOptionSetB only if all non-base properties of both objects match their defaults, but I don’t see how you test for that.

      – supercat

      Dec 28, 2013 at 19:41

    • 10

      The problem with this it that it breaks transitivity. If you add B b2 = new B(1,99), then b.equals(a) == true and a.equals(b2) == true but b.equals(b2) == false.

      – nickgrim

      Jun 25, 2015 at 10:24