The Comparable Interface

The compareTo method belongs exclusively to the Comparable<T> interface and is not part of the Object class. This single abstract method grants a class the ability to establish a natural ordering for its instances.

When a class implements Comparable, it communicates to the Java Runtime Environment how to compare instances of that class. This capability proves essential within the Collections Framework, enabling automatic sorting and maintenance of element uniqueness. Classes lacking this implementation default to having no inherent ordering and must rely on external Comparator implementations for sorting operations.

Contract of the compareTo Method

The method follows a straightforward contract:

• Returns a negative integer when the invoking object precedes the argument
• Returns zero when both objects are equivalent in order
• Returns a positive integer when the invoking object follows the argument

Contractual Guarantees

Implementing compareTo requires adherence to three fundamental properties:

Symmetry: signum(x.compareTo(y)) must equal negative of signum(y.compareTo(x))

Transitivity: If x.compareTo(y) > 0 and y.compareTo(z) > 0, then x.compareTo(z) > 0 must hold

Reflexivity of Equivalence: If x.compareTo(y) == 0, then signum(y.compareTo(x)) must equal signum(y.compareTo(z))

Additionally, aligning compareTo with equals is strongly recommended—specifically, (x.compareTo(y) == 0) should be equivalent to x.equals(y). Achieving this alignment requires using identical value components in both methods.

Consider this implementation:

public class Author implements Comparable<Author> {
    private String penName;
    private int birthYear;

    public Author(String penName, int birthYear) {
        this.penName = penName;
        this.birthYear = birthYear;
    }

    @Override
    public int compareTo(Author other) {
        int nameResult = this.penName.compareTo(other.penName);
        if (nameResult != 0) {
            return nameResult;
        }
        return Integer.compare(this.birthYear, other.birthYear);
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;
        if (obj == null || getClass() != obj.getClass()) return false;
        Author that = (Author) obj;
        return birthYear == that.birthYear && penName.equals(that.penName);
    }
}

While the equality contract recommends consistency between compareTo and equals, this alginment is not strictly mandatory. The distinction lies in their purposes: compareTo produces ordering values for sorting algorithms, whereas equals determines object equality. Sometimes this divergence serves legitimate purposes—such as ordering software packages by version number while identifying them by unique identifiers.

However, divergence creates complications. In ordered collections like TreeSet, mismatched behavior between comparison and equality detection produces unexpected results. Concurrent environments may experience race conditions or deadlock scenarios when comparison logic contradicts equality checks. Maintaining consistency between these methods whenever feasible remains the prudent approach.

Implementation Strategies

Crafting a compareTo method parallels writing equals, with both supporting primitive wrapper static comparison methods. Key distinctions exist:

Comparable is generic, accepting only the same type for comparison—equals, meanwhile, accepts any Object and requires casting. Furthermore, since not all classes implement Comparable, comparing value components from unimplemented types necessitates constructing a separate Comparator.

External Comparison with Comparator

The Comparator<T> interface enables defining ordering rules externally without modifying the compared class. This proves valuable for runtime ordering flexibility or when source code modification isn't possible.

Constructing Comparator Implementations

Create a dedicated class implementing Comparator<T>:

import java.util.Comparator;

public class EmployeeComparator implements Comparator<Employee> {
    @Override
    public int compare(Employee e1, Employee e2) {
        return Integer.compare(e1.getSalary(), e2.getSalary());
    }
}

For one-off usage, inline creation through anonymous classes, lambda expressions, or method references proves more convenient:

// Anonymous inner class
Comparator<Employee> salaryOrder = new Comparator<Employee>() {
    @Override
    public int compare(Employee e1, Employee e2) {
        return Integer.compare(e1.getSalary(), e2.getSalary());
    }
};

// Lambda expression
Comparator<Employee> salaryOrder = (e1, e2) -> 
    Integer.compare(e1.getSalary(), e2.getSalary());

// Method reference with utility
Comparator<Employee> salaryOrder = 
    Comparator.comparingInt(e -> e.getSalary());

The Comparator.comparingInt method accepts a ToIntFunction and returns a comparator extracting primitive int values. Chaining continues through instance methods like thenComparingInt.

The static comparing method offers two overloads:

comparing(Function<T, U> keyExtractor)
comparing(Function<T, U> keyExtractor, Comparator<U> keyComparator)

Both require the extracted value to implement Comparable (U extends Comparable<? super U>). Chaining multiple comparisons produces composite ordering:

Comparator<Employee> compositeOrder = 
    Comparator.comparingInt(Employee::getSalary)
              .thenComparing(Employee::getDepartment);

This example orders employees first by salary, then by department name when salaries match. For specialized sub-comparisons, the second overload accepts an additional comparator:

Comparator<String> reverseAlpha = (s1, s2) -> s2.compareTo(s1);

Comparator<Employee> customOrder = 
    Comparator.comparingInt(Employee::getSalary)
              .thenComparing(Employee::getDepartment, reverseAlpha);