Comparable vs Comparator in Java

Comparable is implemented by the class itself and defines its natural ordering — the single, built-in way its instances should be ordered. The class supplies a compareTo method, and that ordering is then used automatically by Collections.sort, by the sort method on lists, and by the sorted collections such as TreeSet and TreePriorityQueue.

Comparator is a separate object that defines an external ordering. You pass it to the sorting method, so the class does not have to know about it, and you can have several different comparators for the same class — by name, by age, by score.

The distinction matters when you choose between them. Implement Comparable when there is one obvious natural order for the type — a number by its value, a date by its instant. Use a Comparator when the ordering depends on the context, when the type comes from a library you cannot change, or when you need more than one ordering at the same time.

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<Emp> staff = new ArrayList<>(List.of(
                new Emp("Ada", 36), new Emp("Alan", 41), new Emp("Grace", 36)));

        // Natural order: Comparable.
        Collections.sort(staff);
        System.out.println("by age  : " + staff);

        // Explicit order: Comparator.
        staff.sort((a, b) -> a.getName().compareTo(b.getName()));
        System.out.println("by name : " + staff);
    }
}

class Emp implements Comparable<Emp> {
    private final String name;
    private final int age;

    Emp(String name, int age) {
        this.name = name;
        this.age = age;
    }

    @Override
    public int compareTo(Emp other) {
        return Integer.compare(this.age, other.age);
    }

    String getName() {
        return name;
    }

    int getAge() {
        return age;
    }

    @Override
    public String toString() {
        return name + "(" + age + ")";
    }
}

The output shows the two mechanisms. The first sort used the class's own natural ordering, so the employees come out by age. The second sort passed an explicit comparator and reordered them by name.

Two rules to remember. The compare method must return a negative number, zero or a positive number — never the difference of two values, because that overflows for large numbers, so use Integer.compare or Long.compare. And a Comparator should be consistent with equals, otherwise sorted collections behave surprisingly: TreeSet will treat two elements that compare equal as the same element even when they are not equals-equal.

Implement Comparable when the type has one natural ordering that almost every user of the type would agree with. A distance comparing by magnitude, a version number comparing component by component, a timestamp comparing by instant — those are natural orders. If you have to think about what "sorted" should mean for your type, there is probably no natural order and a Comparator is the better choice.

The commitment comes from what Comparable controls. Once a class implements it, the ordering is baked into the type and every sorted collection in the JDK will use it without being told — a TreeSet, a PriorityQueue, a TreeMap keyed by that type, and Collections.sort on a list of them. Changing the natural ordering later is a breaking change, because code that relied on the old order silently changes behaviour.

There is a second, subtler commitment. A Comparable is expected to be consistent with equals: two objects that are equal should compare as equal. If they do not, sorted collections treat them as duplicates while other collections treat them as distinct, and the same two objects behave differently depending on which collection holds them. That inconsistency is the source of some genuinely baffling bugs.

Three practical rules. Implement Comparable only for a natural order that will not change. Make sure compareTo and equals agree. And if the ordering is context-dependent — sorting employees by name in one screen and by performance in another — implement Comparable for the natural order if there is one, and use Comparator objects for the rest.

You chain them. Comparator.comparingInt or Comparator.comparing builds a comparator from a key extractor, thenComparing adds a tie-breaker that is consulted only when the previous criteria compare as equal, and you can keep chaining as many as you need.

The trap is reversed. It reverses the entire chain it is applied to, not just the criterion it appears next to. If you write comparing(A).reversed().thenComparing(B), the reversal applies to A and B is unaffected. If you write comparing(A).thenComparing(B).reversed(), both A and B are reversed. That asymmetry is the source of a lot of "why is only part of my sort backwards" confusion.

import java.util.ArrayList;
import java.util.Comparator;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<Task> tasks = new ArrayList<>(List.of(
                new Task("deploy", 2, "ops"),
                new Task("fix", 1, "core"),
                new Task("refactor", 1, "core"),
                new Task("build", 3, "ops")));

        // Priority ascending, then project, then name.
        tasks.sort(Comparator.comparingInt(Task::getPriority)
                .thenComparing(Task::getProject)
                .thenComparing(Task::getName));
        System.out.println("normal:");
        for (Task t : tasks) {
            System.out.println("  " + t);
        }

        // reversed() here flips the WHOLE chain, not just the last criterion.
        tasks.sort(Comparator.comparingInt(Task::getPriority)
                .thenComparing(Task::getProject)
                .thenComparing(Task::getName)
                .reversed());
        System.out.println("fully reversed:");
        for (Task t : tasks) {
            System.out.println("  " + t);
        }
    }
}

class Task {
    private final String name;
    private final int priority;
    private final String project;

    Task(String name, int priority, String project) {
        this.name = name;
        this.priority = priority;
        this.project = project;
    }

    String getName() {
        return name;
    }

    int getPriority() {
        return priority;
    }

    String getProject() {
        return project;
    }

    @Override
    public String toString() {
        return name + "(p" + priority + ", " + project + ")";
    }
}

The output shows the difference. The first sort orders by priority ascending, so the two priority-one tasks come first, ordered by project and then by name. The second sort reverses everything — priority descending, and within a priority, project and name descending too.

If you only want to reverse one criterion, apply the reversal to that criterion alone: Comparator.comparingInt(Task::getPriority).reversed().thenComparing(Task::getProject) gives descending priority with ascending project. That is the form to reach for when the intent is "highest priority first, but alphabetical within a priority".