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  customer -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  customer 
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.
Posted Date : 2005-11-25 08:53:16.0

N/A

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?
Posted Date : 2005-11-25 21:04:58.0

Equivalator?