Comparator.comparing by Key

Before You Start

Check each box you can do from memory. A box you cannot check yet is not a problem; it points you to a quick refresher, not a grade.

• I can write an unbound instance method reference such as Person::getLastName and explain what it does when applied to a Person object. (See Instance Method Reference on the First Argument.)
• I can explain what target typing means and how a lambda receives its parameter types from context. (See Target Typing and Functional Interfaces.)
• I can state what Comparable requires a class to implement and why it enables natural ordering.

Try This First

The lambda (a, b) -> a.getLastName().compareTo(b.getLastName()) sorts Person objects by last name. Before reading further, count how many times the getLastName method reference appears in this lambda. Then write what you think Comparator.comparing(Person::getLastName) looks like.

What You Need To Walk In With

The Insight: Comparator.comparing(keyExtractor) is function composition: to compare two objects, apply keyExtractor to each (the inner function), then compare the resulting keys (the outer comparison). The same structure as compare(f(a), f(b)) in mathematics, where f is the key extractor. This is why the method reference appears only once: the factory handles the symmetric application to both arguments.

If the factory still feels like magic after reading, trace one call manually: Comparator.comparing(Person::getLastName).compare(pA, pB) is exactly equivalent to pA.getLastName().compareTo(pB.getLastName()). The factory does both steps for you. Once that trace clicks, the pattern becomes the obvious choice for any single-field sort.

You can: produce a Comparator<T> from any Comparable field using one method reference, choose the two-argument overload when you need a non-default key order, reach for comparingInt instead when the key is a primitive int, and explain why the method reference appears only once compared to the equivalent lambda.

How It Works

The one-argument overload

static <T, U extends Comparable<? super U>> Comparator<T>
    comparing(Function<? super T, ? extends U> keyExtractor)

In plain terms: give it a function from T to some Comparable type U; it returns a Comparator<T> that:

1. Applies the function to each of the two T arguments.
2. Compares the resulting U values using their natural order (U.compareTo).

The canonical form with a method reference:

Comparator<Person> byLastName = Comparator.comparing(Person::getLastName);

This reads: “compare Persons by their last name, in last-name natural order.”

The equivalent long form (lambda, written out):

Comparator<Person> byLastName = (a, b) -> a.getLastName().compareTo(b.getLastName());

The factory form expresses the same computation in fewer tokens and with the method reference appearing only once.

The two-argument overload

When the key type does not implement Comparable, or when a non-natural key order is needed, supply a comparator for the keys:

// Case-insensitive last name order
Comparator<Person> byLastNameCI =
    Comparator.comparing(Person::getLastName, String.CASE_INSENSITIVE_ORDER);

The second argument is a Comparator<U> that replaces the default natural order for the key.

When to use comparingInt instead

Comparator.comparing triggers autoboxing when the key is a primitive int. For int keys, use Comparator.comparingInt:

// comparing: autoboxes int to Integer on every call (allocation overhead)
Comparator<Player> bad  = Comparator.comparing(Player::getGamesPlayed);

// comparingInt: no boxing (correct)
Comparator<Player> good = Comparator.comparingInt(Player::getGamesPlayed);

comparingInt, comparingDouble: Primitive-Friendly Variants covers comparingInt, comparingLong, and comparingDouble in full.

Worked Example: Predict Then Check

For a Player class with getLastName(), getTeam(), and getGamesPlayed() (int), write the Comparator.comparing form for each ordering, identifying which overload is appropriate:

(a) Ascending by team name, case-sensitive. (b) Ascending by team name, case-insensitive. (c) Ascending by games played (int field).

// (a) case-sensitive team order
Comparator<Player> a = Comparator.comparing(Player::getTeam);

// (b) case-insensitive team order
Comparator<Player> b = Comparator.comparing(Player::getTeam, String.CASE_INSENSITIVE_ORDER);

// (c) games played (int field, no boxing)
Comparator<Player> c = Comparator.comparingInt(Player::getGamesPlayed);

Quick check

Common Misconceptions

Misconception 1: using Comparator.comparing on a non-Comparable key type

Wrong mental model: “Any method reference works as a key extractor.”

Why it breaks: The one-argument overload requires the key type to implement Comparable. If Person::getCity returns a City class that does not implement Comparable<City>, the compiler reports a type error such as “no instance(s) of type variable(s) U exist so that City conforms to Comparable.”

How to correct: Either (a) add implements Comparable<City> to City and provide compareTo, or (b) use the two-argument overload with an explicit comparator for City values.

Source: Java 25 Comparator.comparing javadoc.

Quick check

Misconception 2: using Comparator.comparing for a primitive key without boxing concern

Wrong mental model: “Comparator.comparing(Player::getGamesPlayed) works fine for int getGamesPlayed().”

Why it matters: The compiler autoboxes int to Integer on each key extraction. For a one-time sort this is negligible. For tight loops, frequent sorts, or large arrays, the repeated Integer allocation adds GC pressure with no benefit. Comparator.comparingInt avoids all boxing.

How to correct: Use Comparator.comparingInt(Player::getGamesPlayed) whenever the key is a primitive int. The API is identical; only the internal implementation differs (no boxing).

Source: Bloch, Effective Java, Item 6.

Formal Definition and Interface Contract

From the Java 25 Comparator API:

static <T, U extends Comparable<? super U>>
    Comparator<T> comparing(Function<? super T, ? extends U> keyExtractor)

Accepts a function that extracts a Comparable sort key from a type T, and returns a Comparator<T> that compares by that sort key.

Two-argument overload:

static <T, U>
    Comparator<T> comparing(Function<? super T, ? extends U> keyExtractor,
                            Comparator<? super U> keyComparator)

Accepts a function that extracts a sort key from a type T, and returns a Comparator<T> that compares by that sort key using the specified Comparator.

Mental Model

Think of Comparator.comparing(keyExtractor) as building a pipeline. Given two objects a and b, the pipeline runs: keyExtractor(a) on one side and keyExtractor(b) on the other, then compares the outputs with the key’s natural order. The key extractor is the inner function; the natural order comparison is the outer function. Comparator.comparing wires the two together without the caller having to write both applications manually.

This is compare(f(a), f(b)) in mathematical notation, where f = keyExtractor and compare is the key’s natural order.

Connections

Within CSCD 210/211: Instance Method Reference on the First Argument introduced Person::getLastName as an unbound instance method reference. This lesson shows its primary production use: as the key extractor argument to Comparator.comparing.

Looking back: The named-class comparators covered in Implementing Comparator<T> as a Named Class (like TeamComparator) can be replaced with Comparator.comparing(Player::getTeam). This lesson is the modern replacement for any single-field named-class comparator on a String or Comparable field.

Looking ahead: reversed, nullsFirst, and nullsLast covers reversed() and thenComparing(), which chain Comparator.comparing calls into multi-key comparators. comparingInt, comparingDouble: Primitive-Friendly Variants covers comparingInt, comparingLong, and comparingDouble.

Go Deeper (optional)

None of what follows is needed to write correct, idiomatic sorting code. It is here for readers who enjoy knowing where an idea comes from.

Where this idea sits in computer science. A Comparator is a binary relation that imposes a total order on its type: the contract rules (antisymmetry, transitivity, totality) are the axioms of a strict total order from order theory. Comparator.comparing then builds a derived total order from an existing one by pulling values through a function. In type theory, this is a covariant transformation: if U has an order, then any function f : T -> U induces an order on T defined by a <= b when f(a) <= f(b).

The design-pattern angle. The function-object passed to Comparator.comparing is the Strategy pattern in its simplest possible form: a single-method object that varies one piece of an algorithm (the key extraction) while the surrounding logic (extract, compare, return sign) stays fixed. This is also the most direct demonstration of a first-class function in Java: instead of naming a subclass, you pass the behavior as data.

The career-relevance angle. In professional Java codebases, Comparator.comparing is the expected form for any single-field sort. Code reviews routinely flag the lambda form (a, b) -> a.getName().compareTo(b.getName()) and suggest replacing it with Comparator.comparing(T::getName). Knowing this pattern and its two-argument overload covers the vast majority of sorting situations you will encounter on the job or in a technical interview.

Going further inside this API. Chaining Comparator.comparing(Player::getTeam).thenComparing(Comparator.comparingInt(Player::getGamesPlayed)) produces a fully declarative multi-key comparator with no explicit comparison logic at the call site. That is covered in reversed, nullsFirst, and nullsLast. The resulting chain reads almost like a sentence, which is the point: the goal of the API design was to make sort specifications as close to spoken English as a statically typed language allows.

Practice

Level 1

Write three comparators using Comparator.comparing:

(a) Comparator<Book> ordering by getTitle() (String), ascending.

(b) Comparator<Book> ordering by getTitle(), case-insensitive.

(c) Comparator<Book> ordering by getPageCount() (int), ascending.

// (a)
Comparator<Book> byTitle = Comparator.comparing(Book::getTitle);

// (b)
Comparator<Book> byTitleCI = Comparator.comparing(Book::getTitle, String.CASE_INSENSITIVE_ORDER);

// (c)
Comparator<Book> byPages = Comparator.comparingInt(Book::getPageCount);

Level 2

Convert the following named comparator class to a single Comparator.comparing expression:

public class PlayerByTeamComparator implements Comparator<Player>
{
    @Override
    public int compare(final Player a, final Player b)
    {
        if (a == null || b == null)
            throw new IllegalArgumentException("Bad Player in PlayerByTeamComparator.compare");
        return a.getTeam().compareTo(b.getTeam());
    }
}

Comparator<Player> byTeam = Comparator.comparing(Player::getTeam);

Level 3

Explain in 3-4 sentences why Comparator.comparing(Player::getTeam) has a structural connection to mathematical function composition. Use the notation compare(f(a), f(b)) in your explanation.

Check Yourself

Close the notes and answer each one from memory, then reveal it. Pulling an idea back from memory is one of the strongest ways to make it stick.