Apache Commons equals/hashCode builder [closed]

Question

I'm curious to know, what people here think about using org.apache.commons.lang.builder EqualsBuilder/HashCodeBuilder for implementing the equals/hashCode? Would it be a better practice than writing your own? Does it play well with Hibernate? What's your opinion?

Answer 1

The commons/lang builders are great and I have been using them for years without noticeable performance overhead (with and without hibernate). But as Alain writes, the Guava way is even nicer:

Here's a sample Bean:

public class Bean{      private String name;     private int length;     private List<Bean> children;  } 

Here's equals() and hashCode() implemented with Commons/Lang:

@Override public int hashCode(){     return new HashCodeBuilder()         .append(name)         .append(length)         .append(children)         .toHashCode(); }  @Override public boolean equals(final Object obj){     if(obj instanceof Bean){         final Bean other = (Bean) obj;         return new EqualsBuilder()             .append(name, other.name)             .append(length, other.length)             .append(children, other.children)             .isEquals();     } else{         return false;     } } 

and here with Java 7 or higher (inspired by Guava):

@Override public int hashCode(){     return Objects.hash(name, length, children); }  @Override public boolean equals(final Object obj){     if(obj instanceof Bean){         final Bean other = (Bean) obj;         return Objects.equals(name, other.name)             && length == other.length // special handling for primitives             && Objects.equals(children, other.children);     } else{         return false;     } } 

Note: this code originally referenced Guava, but as comments have pointed out, this functionality has since been introduced in the JDK, so Guava is no longer required.

As you can see the Guava / JDK version is shorter and avoids superfluous helper objects. In case of equals, it even allows for short-circuiting the evaluation if an earlier Object.equals() call returns false (to be fair: commons / lang has an ObjectUtils.equals(obj1, obj2) method with identical semantics which could be used instead of EqualsBuilder to allow short-circuiting as above).

So: yes, the commons lang builders are very preferable over manually constructed equals() and hashCode() methods (or those awful monsters Eclipse will generate for you), but the Java 7+ / Guava versions are even better.

And a note about Hibernate:

be careful about using lazy collections in your equals(), hashCode() and toString() implementations. That will fail miserably if you don't have an open Session.

---

Note (about equals()):

a) in both versions of equals() above, you might want to use one or both of these shortcuts also:

@Override public boolean equals(final Object obj){     if(obj == this) return true;  // test for reference equality     if(obj == null) return false; // test for null     // continue as above 

b) depending on your interpretation of the equals() contract, you might also change the line(s)

    if(obj instanceof Bean){ 

to

    // make sure you run a null check before this     if(obj.getClass() == getClass()){  

If you use the second version, you probably also want to call super(equals()) inside your equals() method. Opinions differ here, the topic is discussed in this question:

right way to incorporate superclass into a Guava Objects.hashcode() implementation?

(although it's about hashCode(), the same applies to equals())

---

Note (inspired by Comment from kayahr)

Objects.hashCode(..) (just as the underlying Arrays.hashCode(...)) might perform badly if you have many primitive fields. In such cases, EqualsBuilder may actually be the better solution.