为什么Java的Area＃equals方法不会覆盖Object＃equals？

问题描述

我遇到了由Java的 java.awt.geom.Area＃equals（Area）方法引起的问题。问题可以简化为以下单元测试：

I just ran into a problem caused by Java's java.awt.geom.Area#equals(Area) method. The problem can be simplified to the following unit test:

@org.junit.Test
public void testEquals() {
    java.awt.geom.Area a = new java.awt.geom.Area();
    java.awt.geom.Area b = new java.awt.geom.Area();
    assertTrue(a.equals(b)); // -> true

    java.lang.Object o = b;
    assertTrue(a.equals(o)); // -> false
}

经过一番头脑刮擦和调试后，我终于在JDK源代码中看到了 Area 中等于方法的签名如下所示：

After some head scratching and debugging, I finally saw in the JDK source, that the signature of the equals method in Area looks like this:

public boolean equals(Area other)

注意从 @Override 正常的等于方法对象，而只是使用更具体的类型重载方法。因此，上面示例中的两个调用最终调用等于的不同实现。

Note that it does not @Override the normal equals method from Object, but instead just overloads the method with a more concrete type. Thus, the two calls in the example above end up calling different implementations of equals.

由于此行为已被从Java 1.2开始，我认为它不被认为是一个bug。因此，我更感兴趣的是找出为什么决定不正确覆盖等于方法，但同时提供一个超载的变种。 （另一个提示，这是一个真正的决定是没有覆盖 hashCode（）方法。）

As this behavior has been present since Java 1.2, I assume it is not considered a bug. I am, therefore, more interested in finding out why the decision was made to not properly override the equals method, but at the same time provide an overloaded variant. (Another hint that this was an actual decision made is the absence of an overwritten hashCode() method.)

我唯一的猜测是作者担心缓慢的等于区域的实现不适合在放置 Area 时比较相等性s in Set ， Map 等。数据结构。 （在上面的示例中，您可以将 a 添加到 HashSet ，尽管 b 等于 a ，调用包含（b）将失败。）然后，为什么他们不只是以一种不会与等于方法这样的基本概念冲突的方式命名有问题的方法吗？

My only guess would be that the authors feared that the slow equals implementation for areas is unsuitable for comparing equality when placing Areas in Set,Map,etc. datastructures. (In the above example, you could add a to a HashSet, and although b is equal to a, calling contains(b) will fail.) Then again, why did they not just name the questionable method in a way that does not clash with such a fundamental concept as the equals method ?

推荐答案

RealSkeptic链接到在上面的评论中。在解释了推理：

RealSkeptic linked to JDK-4391558 in a comment above. The comment in that bug explains the reasoning:

但是：

所以基本上我们留下了一系列不那么令人愉快的选择，例如：

So basically we're left with an array of not-so-pleasant options, such as:

或：

或者：

或修改等于（Area）行为的其他方法，这些行为会改变其语义或使其与 hashCode 。

or other ways to modify the equals(Area) behavior that would either change its semantics or make it inconsistent with hashCode.

看起来维护人员认为改变这种方法既不可行（因为bug评论中没有提出任何选项可以解决问题）也不重要（因为实现时，该方法非常慢，并且在将 Area 的实例与其自身进行比较时可能只返回true，如评论者所建议的那样。

Looks like changing this method is deemed by the maintainers to be neither feasible (because neither option outlined in the bug comment quite solves the problem) nor important (since the method, as implemented, is quite slow and would probably only ever return true when comparing an instance of an Area with itself, as the commenter suggests).

这篇关于为什么Java的Area＃equals方法不会覆盖Object＃equals？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！