JDK-6355410 : Impossible for subclasses to preserve the equals contract
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86
  • Submitted: 2005-11-25
  • Updated: 2017-06-01
  • Resolved: 2017-06-01
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
A DESCRIPTION OF THE REQUEST:
The properties that the contract equals (found in Object) must fulfill,
is the classical classification of equivalence, which is
- reflexive: for all x, x=x
- symmetric: for all x,y such that x=y, y=x
- transitive: for all x,y,z such that x=y and y=z, x=z
It is not possible to fulfill these properties when attributes can be
added by extending the class. This is a fundamental problem of
equivalence relations in object-oriented languages. More details on
this can be found at
http://developer.java.sun.com/developer/Books/effectivejava/Chapter3.pdf

There is only one solution to this problem. Let C denote a set of
classes such that for any two instances of these classes, we want to be
able to check for the classical classification of equivalence. Then
every class in C must agree on a single contract to be used when
checking for equality, otherwise it is not possible to fulfill the
properties above.

JUSTIFICATION :
As it is today, every class must implement or inherit the equality test
using this common contract. At best, this will only increase redundancy,
but at worst the implementation may lack symmetry or transitivity,
creating bugs which in many cases can be hard to find. Further more, it
is an indication that we need to implement equality in a more object
oriented way when the method equals can not be shadowed within the set
of classes C.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
So how should this be implemented? The most evident way would be to
let a third party determine the common contract as well as doing the
actual checking. This will reduce redundancy, increase consistency,
and most importantly, it makes sure that the properties of equivalence
are fulfilled. In more detail, the third party would be an interface,
much like the Comparator, but with an additional hashing method. More
arguments for this solution can be found in bug reports 5087829, 4269596,
5045681, and 4771660. The only downside I can find is the increase of
complexity, but this is a small price to pay, looking at what we gain.

Comments
The submitter's claims are true if subclassing by multiple maintainers is allowed. If an inheritance hierarchy is maintained by a single maintainer, it is possible, through careful programming, for equality to be well-defined among all members of the family. There is a notion of adding an interface that defines an equivalence function (an Equator, Equalator, Equivocator, etc.) and this may help in certain other cases. But it does appear that a fully general, well-defined, consistent notion of equality in an environment with unbounded subclassing is impossible to achieve. There doesn't seem to be much to do about this. Closing as Won't Fix.
01-06-2017

EVALUATION The problem of equals (and other "binary" operations) in object oriented languages is certainly an interesting one. I don't think we know what the best solution is yet. Without a simple fix, we should probably leave this to the next language. Even if we could come up with a better equals mechanism, it is unlikely we could retrofit existing classes compatibly. For example, some have argued that equals should be independent of mutation on the pair of objects being compared, but many JDK classes violate this. (Otherwise, hash tables containing such objects can be corrupted) The experiment with Comparator was not completely successful, if you look at the details of getting all the types right in the presence of subclassing. (Of course, Comparators are useful in practice) The best reason to work on this is all the fun names you come up with when trying to name these third party equals objects. Equator? Equalizer? Equivocator?
25-11-2005