HashCodeBuilder use, and How and Why are Java hashCode computed for objects with fields?

Question

I am sure there is a good reason, but could you kindly explain why .equals() and .hashCode() do not use reflection to just "work" ?

For example in:

class Test {      
  Integer x = 1, y = 2;
}

Test t1 = new Test();
Test t2 = new Test();
System.out.println(t1.equals(t2)); // returns false
System.out.println(t1.hashCode() == t2.hashCode()); // returns false

I am using HashCodeBuilder and EqualsBuilder to get consistent hashes of simple objects, as in:

class Test {      
  Integer x = 1, y = 2;

  @Override
  public int hashCode() {
    return HashCodeBuilder.reflectionHashCode(this);
  }

  @Override
  public boolean equals(Object obj) {
    return EqualsBuilder.reflectionEquals(this, obj);
  }
}

Test t1 = new Test();
Test t2 = new Test();
System.out.println(t1.equals(t2)); // returns true
System.out.println(t1.hashCode() == t2.hashCode()); // returns true

Could you comment on whether this is the right way to do it?

Afforess · Accepted Answer · 2014-10-26 21:51:37Z

3

HashCodeBuilder and EqualsBuilders are not part of the JDK, they are features of the Apache Commons Lang project. Java doesn't use reflection to "guess" the right equals and hashcode operations because knowing what the programmer intended is impossible. By default, objects do have a default hashcode and equals method (which is why you are overriding them), and each object has a pseudo-unique hashcode and is only equal to itself.

In some programs, it may be correct to have equality and hashcodes unique to each individual object, rather than reflectively inspecting the fields at runtime. In other programs, programmers may which to disregard certain fields and have equality and hashcode only operate on a subset of an objects fields. There are infinitely many possibilities and combinations of fields that a programmer might intend or not intend to use for equality, which is why Java makes the safest assumption and makes each object equal only to itself.

answered Oct 26, 2014 at 21:51

Afforess

9347 silver badges15 bronze badges

Sign up to request clarification or add additional context in comments.

3 Comments

Hugo Zaragoza Over a year ago

1. "are not part of the JDK, they are features of the Apache Commons" : yes but my questions is whether I am making a reasonable use, or are there better alternatives.

Hugo Zaragoza Over a year ago

2. with respect to "doing the right thing", I understand what you are saying ofcourse, but my question was that it seems the default should be something more "equals" like, I was wondering why Java chose to have such default implementations, which seem to be useful in very few cases only.

Afforess Over a year ago

I explained why Java's default assumption was chosen, it is the safest. By default, Java's equals and hashCode is always correct for an object with regards to itself. Java can't know the programmers intentions, so reflectively analyzing fields would be "magic behavior" and would be a surprising result to most people. As for using EqualsBuilder and HashCodeBuilder, yes, you are using them correctly. Such tools are so popular they were introduced as part of Java 7. You can use Objects.equals(a, b) or Objects.hashCode(...)

Collectives™ on Stack Overflow

HashCodeBuilder use, and How and Why are Java hashCode computed for objects with fields?

1 Answer 1

3 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

3 Comments

Your Answer

Sign up or log in

Post as a guest

Related