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.