Should compareTo and equals be consistent if the Object is mutable and will not be used in sorted Set, etc.

Question

The Java documentation for Comparable recommends that compareTo be consistent with equals (because of the behavior in sorted sets or sorted maps).

I have a Player object which is mutable. Player will not be used in any kind of sorted set or sorted map.

I want to have an array of Players (Player[]) and assign each player a random order of play (a member variable m_nPlayOrder), then sort them in that array based on their m_nPlayOrder member variable.

I will implement the Comparable interface and the compareTo function to achieve this.

My question is, is it ok in this case if Player has a compareTo that is NOT consistant with equals? It will not be consistant with equals unless I also override equals (and hashCode) and have it return true if the Players m_nPlayerOrder are equal. I do not want to do that.

UPDATE: Thanks everyone for the replys! I'm going with implementing the Comparator instead of Comparable.

Answer 1

You could implement a java.util.Comparator (a stand-alone object that "knows" your Player class and compares accordingly) and use that instead of implementing Comparable in the class.

Comparator has the advantage in that you can implement any number of them for different types of sorts, rather than the single Comparable.

Answer 2

It is not a good practice to implement equals and compareTo that are inconsistent.

Player will not be used in any kind of sorted set or sorted map.

The problem is that someone else trying to maintain your code at some time in the future may not realize that you have implemented inconsistent methods, and may try to put a Player into a sorted set/map or some other data structure that expects consistent methods.

There is a good alternative available to you in the form of standalone Comparator objects.

Answer 3

The Comparable API says, "It is strongly recommended (though not required) that natural orderings be consistent with equals." If you don't, be certain to document the limitations you noted. Alternatively, it may be easy to implement Comparable fully, as suggested in this answer.

Answer 4

I do not think you have the problem that you think you have, but perhaps I'm missing something (wouldn't be the first time).

The requirement here is that 2 objects that are equal should also return 0 for compareTo(), meaning that they occupy the same rank for sorting purposes. There is a separate requirement that 2 equal objects should also have the same hashCode. But this isn't a concern for you, because you're overriding neither equals() nor hashCode(); the Java platform will satisfy this one for you.

Since your objects will be equal based on reference comparison (not custom, logical comparison), you won't have a problem unless your objects don't compare to themselves. In orther words, as long as a single object, when asked to compareTo() itself, would always return 0, you're fine.