Collection.remove(Object) and Collection.contains(Object) must use the
Object argument together with some kind of relation (hopefully an equivalence
relation) to determine which elements qualify as being the "same" as the argument.

As usual, it depends on what your definition of "is" is.

The spec in Collection clearly states that the .equals() "equator" should be used.
But some other obvious equators are likely to be desired by the user:
- reference equality
- the equator induced by a comparator, i.e.
  a "is" b iff c.compare(a,b) == 0

Resolving this satisfactorily is rather tricky. Probably the contract for
contains/remove should be weakened, but it should be specified that
contains and remove must use the SAME equator, the equator for ordered collections
like SortedSet should be specified to be the equator induced by its ordering,
and it should be required that each concrete collection class specify what
equator is in use. PriorityQueue should use .equals() in spite of its having
an ordering.

Doug Lea wrote (in a slightly different context)

"Here's my proposal for the easiest of them:
In Collection, add to specs somewhere that any implementation
using a comparator is free to use it as a equality function,
and similarly for Comparables.
(Wording this just right is a minor challenge.)
...
Collection.contains() and friends have overly constraining specs.

On the broader issue of whether there should be collection
classes that allow user-defined equality functions, I think
it would be OK to acommodate this, but only in classes that advertised
their lack of guaranteed compliance to symmetry properties.
(See disclaimers in IdentityHashMap), and that indicate that
you are paying some overhead for the privilege.

In the case of hash tables, this meshes with the informal
proposal I put out to add a hash table class that is selectively
(via constructor arguments) weak in key and/or value, and
can use either identitiy or equals. Alternatively using an Equator seems
like a reasonable thing to add to kill yet more birds with one stone.

Josh is more than right to be wary of the cost of doing
this sort of thing in existing classes. It's been a long while, but
last time I tested such variants, the cost was very noticeable.
I do not want to see further mandated slowdowns of
core collection classes. It just drives people to use
other collections packages."
###@###.### 2005-05-16 02:08:09 GMT