Why doesn't invalid compareTo cause Collections.sort to crash?

Question

Consider the following compareTo method, implementing the Comparable<T> interface.:

@Override
public int compareTo(MyObject o)
{
    if (o.value.equals(value)
        return 0;
    return 1;
}

Apparantly, the programmer implemented the compareTo as if it was equals(). Obviously a mistake. I would expect this to cause Collections.sort() to crash, but it doesn't. Instead it will just give an arbitrairy result: the sorted result is dependant on the initial ordering.

public class MyObject implements Comparable<MyObject>
{

    public static void main(String[] args)
    {
        List<MyObject> objects =
                Arrays.asList(new MyObject[] {
                        new MyObject(1), new MyObject(2), new MyObject(3)
                });
        Collections.sort(objects);
        System.out.println(objects);

        List<MyObject> objects2 =
                Arrays.asList(new MyObject[] {
                        new MyObject(3), new MyObject(1), new MyObject(2)
                });
        Collections.sort(objects2);
        System.out.println(objects2);
    }

    public int  value;

    public MyObject(int value)
    {
        this.value = value;
    }

    @Override
    public int compareTo(MyObject o)
    {
        if (value == o.value)
            return 0;
        return 1;
    }

    public String toString()
    {
        return "" + value;
    }

}

Result:

[3, 2, 1]
[2, 1, 3]

Can we come up with a use case for this curious implementation of the compareTo, or is it always invalid. And in case of the latter, should it throw an exception, or perhaps not even compile?

Answer 1

There's no reason for it to crash or throw an exception.

You're required to fulfil the contract when you implement the method, but if you don't, it just means that you'll get arbitrary results from anything that relies on it. Nothing is going to go out of its way to check the correctness of your implementation, because that would just slow everything down.

A sorting algorithm's efficiency is defined in terms of the number of comparisons it makes. That means that it's not going to add in extra comparisons just to check that your implementation is consistent, any more than a HashMap is going to call .hashcode() on everything twice just to check it gives the same result both times.

If it happens to spot a problem during the course of sorting, then it might throw an exception; but don't rely on it.

Answer 2

Violating the contract of Comparable or Comparator does not necessarily result in an exception. The sort method won’t spend additional efforts to detect such a situation. Therefore, it might result in an inconsistent order, an apparently correct result or in an exception being thrown.

The actual behavior depends on the input data and the current implementation. E.g. Java 7 introduced TimSort in it’s sort implementation which is more likely to throw an exception for inconsistent Comparable or Comparator implementations than the implementations of earlier Java releases. This might spot errors that remained undetected when using previous Java versions, however, that’s not a feature to aid debugging in the first place, it’s just a side-effect of more sophisticated optimizations.

---

Note that it isn’t entirely impossible for a compiler or code audit tool to detect asymmetrical behavior of a compare method for simple cases like in your question. However, as far as I know, there are no compilers performing such a check automatically. If you want to be on the safe side, you should always implement unit tests for classes implementing Comparable or Comparator.

Answer 3

According to the documentation, Collections.sort() uses a variant of merge sort, which divides the list into multiple sublists and then repeatedly merge those lists repeatedly; the sorting part is done during the merging of those lists; if your comparison method is arbitrary, what will happen is that this merging will be done in an arbitrary order.

Answer 4

As a result of this every element is bigger than all the other elements.

Depending on the mathematical group or order you want to represent it may be a valid case and therefore there is no reason to throw any errors. However the example you show does not represent the natural ordering of numbers as you know them by standard.

The presented order is not total.

==EDIT==

Thanks for the comment, indeed it is not allowed by the specification to use the compareTo method to implement non-total or non-antisymmetric orders.