United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4771660 (coll) Comparator, Comparable, Identity, and Equivalence
JDK-4771660 : (coll) Comparator, Comparable, Identity, and Equivalence

Details
Type:
Enhancement
Submit Date:
2002-10-31
Status:
Open
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
Component:
core-libs
OS:
solaris_8,windows_xp
Sub-Component:
java.util:collections
CPU:
x86,generic
Priority:
P5
Resolution:
Unresolved
Affected Versions:
1.2.1,1.4.2
Targeted Versions:

Related Reports
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
The Object methods equals and hashValue define an equivalence relation
among objects. Similarly, the Comparable method compareTo defines an ordering.

The Comparator interface defines a way to impose an external ordering among
objects.  Why isn't there similarly a way to impose an external equivalence
relation among objects?

I have some nontrivial applications in which I'd like to look at a set of
objects from different points of view (that is, under different equivalence
relations at different points in my code), but the absence of an externally
imposable equivalence relation forces me to wrap all the objects in order
to view them under a different equivlence relation.  If I'm lucky then the
two default equivalence relations (identity and natural) may be just what I
need, but I suspect not.

If there were an externally imposable equivalence relation, it would be
an interface with two methods:
     interface Equivalence {
	int hashValue(Object);
	boolean equals(Object, Object);
     }

Two standard (and trivial) instances would be provided: the identity
equivalence relation and the natural equivalence relation.

I believe separating things this way makes it much easier to have a number
of interesting variants on maps and sets without providing wholly new
implementations.  If the constructors are static factories, we would still
have the flexibility to fully specialize the implementation for performance
when one of the two standard equivalence relations is given to the static
constructor.

This kind of functionality can be added without making any of the existing
classes obsolete.

                                    

Comments
EVALUATION

> The Object methods equals and hashValue define an equivalence relation
> among objects. Similarly, the Comparable method compareTo defines an ordering.
>
> The Comparator interface defines a way to impose an external ordering among
> objects.  Why isn't there similarly a way to impose an external equivalence
> relation among objects?

   We wanted to avoid the complexity. We seriously entertained this notion
at the time the collections framework was designed, but rejected it.  The
power-to-weight ration seemed to low.  We felt that equals was what you
wanted 95% of the time; ==, 4%; and something else 1%.  Writing sensible
contracts for bulk operations when is very tricky when equality predicates
differ.

> I have some nontrivial applications in which I'd like to look at a set of
> objects from different points of view (that is, under different equivalence
> relations at different points in my code), but the absence of an externally
> imposable equivalence relation forces me to wrap all the objects in order
> to view them under a different equivlence relation.

    Yes, I admit that this is a pain in the butt.

>  If I'm lucky then the
> two default equivalence relations (identity and natural) may be just what I
> need, but I suspect not.

    I'd be curious to know more about the application (preferably in person
rather than by e-mail).

> If there were an externally imposable equivalence relation, it would be
> an interface with two methods:
>      interface Equivalence {
>          int hashValue(Object);
>          boolean equals(Object, Object);
>      }

    Yep.  I'm not sure I'd call it "Equivalence," but I'm not quite sure
what I'd call it.  Perhaps EquivalenceRelation, or EqualityPredicate?
(Neither of those names are any good either.)

> Two standard (and trivial) instances would be provided: the identity
> equivalence relation and the natural equivalence relation.

> I believe separating things this way makes it much easier to have a number
> of interesting variants on maps and sets without providing wholly new
> implementations.  If the constructors are static factories, we would still
> have the flexibility to fully specialize the implementation for performance
> when one of the two standard equivalence relations is given to the static
> constructor.
>
> This kind of functionality can be added without making any of the existing
> classes obsolete.
>
> What do you think?

    See above.  I suppose I could be convinced otherwise by compelling
examples.  We should also involve <###@###.###> in these discussions.

                                     
2004-09-08



Hardware and Software, Engineered to Work Together