JDK-6270657 : (coll) remove/contains and "Equators" other than .equals()
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:collections
  • Affected Version: 6
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2005-05-16
  • Updated: 2024-02-12
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
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

Comments
An "Equalable" interface should also be generic in order to provide better compile-time type safety, similar to Comparator. This will remove a class of errors, where an object of the wrong type is passed to equals(), causing it to return false at runtime instead of being an error at compile time.
15-06-2017

If there is a way to provide an alternative function to equals(), there will also need to be a way to provide an alternative hashCode().
02-09-2016

EVALUATION It's hard to design a really good Collections API. Deep thought required. ###@###.### 2005-05-16 02:08:09 GMT
16-05-2005