Why does Java's Area#equals method not override Object#equals?

Question

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.j         


        

Answer 1

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

The problem with overriding equals(Object) is that you must also override hashCode() to return a value which guarantees that equals() is true only if the hashcodes of the two objects are also equal.

but:

The problem here is that Area.equals(Area) does not perform a very straight-forward comparison. It painstakingly examines each and every piece of geometry in the two Areas and tests to see if they cover the same enclosed spaces. Two Area objects could have a completely different description of the same enclosed space and equals(Area) would detect that they were the same.

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

deprecate equals(Area) and create an alternate name for that operation, such as "areasEqual" so as to avoid the confusion. Unfortunately, the old method would remain and would be linkable and would trap many people who were intending to invoke the equals(Object) version.

or:

deprecate equals(Area) and change its implementation to be exactly that of equals(Object) so as to avoid semantic problems if the wrong method is called. Create a new method with a different name to avoid confusion to implement the old functionality provided by equals(Area).

or:

implement equals(Object) to call equals(Area) and implement a dummy hashCode() which honors the equals/hashCode contract in a degenerate way by returning a constant. This would make the hashCode method essentially useless and make Area objects nearly useless as keys in a HashMap or Hashtable.

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

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).