The Comparable Interface

Imagine a program that builds a list of words, asks Java to put them in order, and then prints the list. Sorting looks like a single step, but it touches several parts of the language at once: the list, the items inside it, and a utility method that does the work. This article approaches the topic from the outside in. You will first see what happens when a list is sorted, then learn which rules govern the order, and finally learn how to change that order with a Comparator.

As you read, keep one question in mind: when the sorted output is not what you expected, where in the chain of steps did the result diverge? Learning to answer that question is the real skill this article builds.

A natural first guess is that the List interface would provide a sort method, since sorting a list seems like a basic operation. It does not. The likely reason is that sorting only makes sense for certain kinds of objects, so the designers of the interface left it out. Instead, the sorting methods are static methods of a separate class, java.util.Collections.

Sorting a list is therefore a call on the Collections class rather than a method you invoke on the list itself. You pass the list in as an argument. If you have used the Arrays class to sort arrays, the idea is similar: a helper class supplies the operation, and you supply the data.

Collections.sort() is a static method of the java.util.Collections class. With a single argument, the list, it sorts the list into ascending order. The list is the thing being rearranged; the Collections class is the helper that performs the work.

The source material gives two families of examples where this holds: Strings, and wrapper classes such as Integer and Double. Those types already know how to compare themselves, so Collections.sort() can rely on that knowledge. A Comparable item carries its own ordering rule, which is why the single-argument form needs nothing else from you.

Here is the single-argument form in action. The list starts with pear, apple, and mango. After the call, the same list object holds the items in ascending order.

The before row shows the list as it was added, and the after row shows the same three positions once the sort finishes. Each position now holds a different word. The list object itself was rearranged, which is why printing it afterward shows the sorted order.

Sometimes the natural ordering is not the one you want, or the items do not implement Comparable at all. For those cases there is a second form of the call that takes a Comparator as its second argument. When a comparator is supplied, Collections.sort() uses it to compare items in the list, instead of relying on the items' own natural ordering.

The comparator is a separate object, so the ordering rule lives outside the items. This is what makes the second form useful for custom orders. The same items can be sorted in different ways by passing different comparators, without changing the items themselves.

Consider a list of words that should be ordered by how many characters each word has, rather than alphabetically. A Comparator can express that rule. The example below is an original illustration written for this article, not taken from the source. It defines a comparator whose compare() method compares the lengths of two Strings.

Read the compare() method as the rule. It receives two words and returns a number. The sign of that number tells the sort how the two items relate. Here the rule says that a shorter word comes before a longer one. Collections.sort() calls this rule on pairs of items from the list, so the rule, not the items' natural ordering, decides the final arrangement.

The sequence diagram shows the two-argument route. The calling code makes one call to Collections.sort(). The sort then repeatedly asks the comparator to compare pairs of items, and it uses each returned sign to decide the arrangement. The comparator's compare() method is therefore the place where the ordering rule is applied, while Collections.sort() handles the rearranging.