HashCodeBuilder使用,以及为具有字段的对象计算Java hashCode的方式和原因?

时间:2014-10-26 21:00:13

标签: java reflection equals hashcode

我确信有充分的理由,但是你能否解释为什么.equals()和.hashCode()不使用反射来“工作”?

例如:

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

我正在使用HashCodeBuilder和EqualsBuilder来获得简单对象的一致哈希,如:

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

你能评论这是否是正确的方法吗?

1 个答案:

答案 0 :(得分:3)

HashCodeBuilder和EqualsBuilders不是JDK的一部分,它们是Apache Commons Lang项目的功能。 Java不使用反射来“猜测”正确的等号和哈希码操作,因为知道程序员的意图是不可能的。默认情况下,对象确实有一个默认的hashcode和equals方法(这就是你覆盖它们的原因),每个对象都有一个伪唯一的hashcode,只等于它自己。

在某些程序中,为每个单独的对象提供唯一的相等和哈希码可能是正确的,而不是在运行时反射检查字段。在其他程序中,程序员可能忽略某些字段并且具有相等和散列码仅在对象字段的子集上操作。程序员可能打算或不打算使用相等的无限多种可能性和字段组合,这就是为什么Java做出最安全的假设并使每个对象只与自身相等。