Collection.equals

Question

The javadocs for collection.equals states
"The general contract for the Object.equals method states that equals must be symmetric (in other words, a.equals(b) if and only if b.equals(a)). The contracts for List.equals and Set.equals state that lists are only equal to other lists, and sets to other sets. Thus, a custom equals method for a collection class that implements neither the List nor Set interface must return false when this collection is compared to any list or set. (By the same logic, it is not possible to write a class that correctly implements both the Set and List interfaces.) "
Why not? Couldn't a class implement both List and Set and compare either way, depending on what kind of object it is being compared with?
FYI I grumbled about equals before in a previous post
http://forum.java.sun.com/thread.jspa?forumID=425&threadID=619976
I was just working on something and came across a bug in my code because I was hashing something using an arrayList as a key, and I believed incorrectly that equals would be implemented the same way it is for arrays.
It seems weird to me that Collection, List and Set require symmetry and transitivity between all classes implementing them, but CharSequence (an interface implemented by both String and StringBuffer, ala my other post) does not.
CharSequence states:
"This interface does not refine the general contracts of the equals and hashCode methods. The result of comparing two objects that implement CharSequence is therefore, in general, undefined. Each object may be implemented by a different class, and there is no guarantee that each class will be capable of testing its instances for equality with those of the other. It is therefore inappropriate to use arbitrary CharSequence instances as elements in a set or as keys in a map"
Ok. So the guys working on Java have given us at least three or four different patterns to follow here: There are arrays which we know are only equal if they are the same array. There's the Object (general) implementation of equals in which we can count on objects of different classes being different. There's List and Set where all lists and sets are equal to other lists and set respectively, and there's the CharSequence pattern in which all bets are off.
Wouldn't it be easier for people to learn and program in java if they could rely on one of these patterns without having to go through the javadocs with a fine toothed comb?

Answer 1

No.
Let's say you have a List, (L) a Set (S) and a
List/Set (LS).
You want both of the following to be able to be
true:
LS.equals(L)
LS.equals(S)
However, symmetry and transitivity combine to tell us
that L.equals(S) and S.equals(L) must also return
true.
The contracts for List and Set require L.equals(S)
and S.equals(L) to return false.
Ah ok. Thanks for clearing that up for me. It seems kind of limiting to say that there could never be a collection that is both a list and a set, but I guess it wouldn't be too hard to work around.
Object and arrays use the same equals method--only
returns true if the references are equal.Yes, I meant Object in the general sense, not the Object class itself. So things like Integer(5) can be equal to another Integer, but never to a Float.
There's List and Set where all lists and
sets are equal to other lists and setrespectively,
No. Any List can be equal to any other List,
and any Set can be equal to any other Set. In
both cases, it depends on what elements the
collection contains.Right, sorry that's what I meant to say.
It makes sense that List and Set define equals the
way they do. Since Lists are ordered, it makes sense
that the order should matter in determining equality.
Since Sets are not ordered, it would not make
sense to use order in determining equality.Naturally. But it might also make sense just to say that lists and sets are only equal to themselves.
and there's the CharSequence pattern in which all
bets are off.There's nothing special about CharSequence. It's just
another interface that doesn't define a specific
equals implementation.Yes. What I was trying to get at is that while in general objects (such as subclasses of Number) are only be equal to objects of the same class, and lists and sets must be equal to other lists and sets, respectively, that CharSequence says that some subclasses MAY be comparable using equals.
However, ease of learning is not the one and only
supreme driving force behind the design of the
language and the APIs.Acknoledged. What I mean is that with equals following all these different patterns, it is easy to make a mistake that goes unnoticed until software is in the hands of the clients.
Rather than trying to cram equals (or anything else)
into a fixed set of pigeonholes, you'd be better
served to try to undertand the fundamental purpose
behind it and what kinds of factors go into deciding
what the appropriate implementation is in a given
situation.Ok. What is the fundamental purpose behind equals? Not trying to be hostile here, I'm just curious. I know that one of the biggest factors is with collections and such questions as hashing and contains. Another big one is String.equals(...) to compare strings. Are there any others?
I'm just trying to figure out how it might be possible to make equals() more opaque in future languages, so that people can read the basic definition of equals given in Object and know how it is used and how to use it. If you think that it is already clear and easy to use, consider that using FindBugs (google for FindBugs if you are interested) I found a bug in the java source in ChoiceFormat that has existed since ChoiceFormat's inception in Java 1.1 in which it calls equals between a StringBuffer and a String. If the people working on designing Java can make these mistakes, what hope have the rest of us?