Comparable vs Comparator

For this lesson, we'll focus on ordering in the Collections module: the compareTo contract, when to use Comparable versus Comparator, safe comparator chains, the sorting APIs, and how TreeMap, TreeSet and PriorityQueue use comparison. We will link to the Core Java comparison lesson for identity and equality, so we do not repeat the whole == / equals story here. Interviewers ask this because a one-line comparator can look harmless while breaking a set, a heap or TimSort in production.

01Picture it first: one built-in rule, many outside rules

Imagine a company archive. Each employee badge has one official employee number printed on it, so the archive can always file employees by number. That is Comparable: the object carries its default filing rule.

Now imagine the support team asks for employees by last name, finance asks for salary band, and security asks for badge expiry date. Those are Comparators: external strategies that can change per use case without editing the Employee class.

Fig. 1

Comparable lives inside the class as the natural order, while Comparator objects live outside and can order the same objects by different keys, then a comparator chain compares customer, amount and id in order

Notice the shape. Comparable answers "how should this type normally be ordered?" once. Comparator answers "how should I order it here?" as many times as you need.

02Natural ordering under the hood

Comparable<T> has one method: int compareTo(T other). The exact magnitude does not matter. Java only reads the sign: negative means this comes before other, zero means they occupy the same ordering slot, and positive means this comes after.

import java.time.LocalDate;

public record Shipment(String id, LocalDate promisedDate, int priority)
        implements Comparable<Shipment> {

    @Override
    public int compareTo(Shipment other) {
        int byDate = promisedDate.compareTo(other.promisedDate);
        if (byDate != 0) return byDate;

        int byPriority = Integer.compare(other.priority, priority); // higher first
        if (byPriority != 0) return byPriority;

        return id.compareTo(other.id); // tie-breaker keeps compareTo aligned with equals
    }
}

Notice three things:

• The method returns by sign, not by distance. -1, -17 and Integer.MIN_VALUE all mean "before".
• Integer.compare avoids arithmetic overflow and makes the descending priority explicit by swapping the operands.
• The final id comparison means two different shipments do not compare as 0 unless all record components are equal.

The Comparable contract is short, but it is not optional. For any x, y and z, antisymmetry means sgn(x.compareTo(y)) == -sgn(y.compareTo(x)); transitivity means x > y and y > z implies x > z; and consistent ties mean if x.compareTo(y) == 0, then x and y compare the same way against every z. The javadoc also strongly recommends consistency with equals: x.compareTo(y) == 0 should mean x.equals(y).

That last rule is where interviews get interesting. It is not required by the compiler, but collections that use ordering treat 0 as "same key" or "same element". If equals says two objects differ but comparison says 0, a sorted collection follows comparison.

The BigDecimal trap, briefly

BigDecimal is the classic exception, and the Core Java lesson covers it in more depth: Comparing objects in Java. Its equals includes scale, so new BigDecimal("1.0") and new BigDecimal("1.00") are not equal. Its compareTo ignores scale for numeric comparison, so they compare as 0.

import java.math.BigDecimal;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import java.util.TreeSet;

BigDecimal onePointZero = new BigDecimal("1.0");
BigDecimal onePointZeroZero = new BigDecimal("1.00");

Set<BigDecimal> hashSet = new HashSet<>(List.of(onePointZero, onePointZeroZero));
Set<BigDecimal> treeSet = new TreeSet<>(List.of(onePointZero, onePointZeroZero));

System.out.println(hashSet.size()); // 2: hashCode + equals include scale
System.out.println(treeSet.size()); // 1: compareTo says same numeric value

HashSet uses hashCode and equals. TreeSet uses compareTo or the supplied Comparator, and a comparison result of 0 means "already present". That is why I usually normalize BigDecimal values at boundaries if they are keys or set elements, for example with a fixed money scale.

03Comparator as an external strategy

Comparator<T> is a functional interface: int compare(T a, T b). It is what you use when the class has no natural order, when you do not own the class, or when the screen has a different order from the domain default. In real code, you should almost never write the comparison branches yourself.

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

record Order(String id, String customer, int totalCents, String coupon) {}

List<Order> orders = new ArrayList<>(List.of(
        new Order("o-3", "Ravi", 1200, "FESTIVE"),
        new Order("o-1", "Asha", 1200, null),
        new Order("o-2", "Asha", 900, "WELCOME")));

Comparator<Order> bySupportQueue = Comparator
        .comparing(Order::customer, Comparator.naturalOrder())
        .thenComparing(Comparator.comparingInt(Order::totalCents).reversed())
        .thenComparing(Order::coupon, Comparator.nullsFirst(Comparator.naturalOrder()))
        .thenComparing(Order::id);

orders.sort(bySupportQueue);
System.out.println(orders);

Notice four details:

• Comparator.comparing(Order::customer) extracts a key and compares the key with its natural order. The two-argument form lets you pass a key comparator explicitly.
• thenComparing runs only when the previous step returns 0, so the chain reads like a sequence of tie-breakers.
• comparingInt avoids boxing int keys into Integer objects during comparison. The same idea exists for long and double.
• nullsFirst wraps a comparator and says what to do with null keys or elements. Without it, naturalOrder() throws NullPointerException when it sees null.

Here is the catch with reversed(): it reverses the comparator object it is called on. If you write Comparator.comparing(Order::customer).thenComparingInt(Order::totalCents).reversed(), you reverse both customer and total. If only the total should go high to low, reverse only that step, as shown above.

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

List<Integer> values = new ArrayList<>(List.of(5, Integer.MIN_VALUE, 3));
values.sort((a, b) -> a - b);
System.out.println(values); // [3, 5, -2147483648], wrong

values.sort(Integer::compare);
System.out.println(values); // [-2147483648, 3, 5]

04Sorting in Java: which API does what

Sorting is where Comparable and Comparator meet the library. The simple rule is: pass null or no comparator to use natural order, pass a comparator for caller-chosen order. The more complete answer includes stability and primitive arrays.

Stability means equal elements keep their original relative order. If you sort orders by amount and then stably sort by customer, the orders inside each customer group stay amount-sorted. I still prefer one comparator chain over multi-pass sorting in production because it states the intent in one place.

For maps, remember that a HashMap itself is not sorted by value. The usual pattern is to sort its entrySet() into a list or stream result, which we cover in Everyday Map operations. Use TreeMap when you need keys kept sorted as the map is updated.

05Advanced: sorted collections, heaps and broken contracts

TreeMap and TreeSet are red-black tree structures. They use the natural order of keys/elements unless you pass a comparator at construction time. Every lookup, insertion and removal walks the tree with comparison, so a result of 0 means "same key" in TreeMap and "same element" in TreeSet.

import java.util.Comparator;
import java.util.NavigableSet;
import java.util.TreeSet;

record Task(String id, int priority) {}

NavigableSet<Task> tasks = new TreeSet<>(
        Comparator.comparingInt(Task::priority).reversed()
                  .thenComparing(Task::id));

tasks.add(new Task("index", 10));
tasks.add(new Task("email", 10));
System.out.println(tasks.first()); // Task[id=email, priority=10]

The id tie-breaker matters. If the comparator used only priority, those two tasks would compare as 0, and the second insert would be treated as a duplicate. That is not a TreeSet bug. It is the comparator saying the two tasks occupy the same sorted slot.

PriorityQueue also uses natural order or a comparator, but it is a heap, not a sorted list. peek() and poll() give you the least element according to the comparator, or the greatest if your comparator reverses the order. Iterating the queue does not produce sorted output; it walks the heap array.

import java.util.Comparator;
import java.util.PriorityQueue;

record Incident(String id, int severity) {}

PriorityQueue<Incident> queue = new PriorityQueue<>(
        Comparator.comparingInt(Incident::severity).reversed()
                  .thenComparing(Incident::id));

queue.add(new Incident("db", 3));
queue.add(new Incident("cache", 1));
queue.add(new Incident("api", 3));

while (!queue.isEmpty()) {
    System.out.println(queue.poll()); // api severity 3, db severity 3, cache severity 1
}

The TimSort exception

List.sort and object Arrays.sort use TimSort, a stable merge sort optimized for already partially ordered data. During merging it checks assumptions that rely on comparator transitivity. If a comparator says a < b, b < c and then c < a, TimSort can throw IllegalArgumentException: Comparison method violates its general contract!.

That exception often appears only with enough data and the right shape of runs. A unit test with five elements can pass for months. Then production sorts 50,000 rows where a comparator reads mutable state or uses a non-transitive rule, and the sort fails.

Nulls, natural order and default choices

Natural ordering generally does not accept null. TreeSet with natural ordering and List.sort(null) will throw when they need to compare a null element. If nulls are legitimate data, say how they should order.

Comparator<String> names = Comparator.nullsLast(String.CASE_INSENSITIVE_ORDER);

The simple option is natural order: list.sort(null) or new TreeSet<>(). It stops being enough when the domain has more than one useful order, when nulls are allowed, or when equality and order would disagree. My default is to keep Comparable for obvious value types and put business-screen ordering in named comparators.

06How to say it in the interview

When I ask this, I'm listening for five things: you know the sign-based contract, you separate natural order from caller-provided order, you avoid subtraction, you know sorted collections use comparison instead of equals, and you can name which Java sorts are stable. The strong answer also mentions BigDecimal and TimSort's contract exception without turning the answer into a lecture on equals.

Comparable<T>
- inside the class: one natural order
- compareTo sign: <0, 0, >0
- contract: antisymmetry, transitivity, consistent ties
- prefer: compareTo == 0 iff equals == true

Comparator<T>
- outside strategy: many orders per type
- comparing / thenComparing / reversed / nullsFirst
- comparingInt/Long/Double avoid boxing
- never a - b, use Integer.compare(a, b)

Collections that compare
- TreeMap/TreeSet: compare == 0 means same key/element
- PriorityQueue: heap order for poll, iterator not sorted
- HashSet: hashCode + equals, so BigDecimal 1.0/1.00 size differs

Sorting
- List.sort, Collections.sort, Arrays.sort(Object[]): stable TimSort
- Arrays.sort(primitives): dual-pivot quicksort, not stable
- parallelSort: large arrays, fork-join overhead
- bad comparator -> "violates its general contract"