Writing a Comparator as a Lambda

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 anonymous-class Comparator and identify its compare method signature.
• I can state what return value compare must produce to signal “first argument is less than second.”
• I can explain why a functional interface can be satisfied by a lambda (one abstract method only).

Try This First

You have an array of Player objects and you want to sort them by games played, ascending. Here is the anonymous-class version:

Arrays.sort(players, new Comparator<Player>() {
    @Override
    public int compare(Player a, Player b) {
        return Integer.compare(a.getGamesPlayed(), b.getGamesPlayed());
    }
});

Before reading the next section, count the characters that carry the actual logic versus the characters that are boilerplate. Then predict: what is the minimum you would need to keep if you could strip everything else away?

What You Need To Walk In With

A lambda is the same one-method function object as the anonymous class, written inline because Comparator is a functional interface. The compiler fills in the type, the class declaration, the method name, and the @Override annotation automatically. If writing any of this feels like a lot at once, focus on Form 1 alone: two parameter names, an arrow, and one expression. That covers the vast majority of real sorting code, and the other forms follow naturally once Form 1 is solid.

You can: write a Comparator<T> lambda in expression form for a single-expression body, write the block form when the body needs more than one statement, identify the inferred parameter types, and translate an anonymous-class Comparator into its lambda equivalent.

How It Works

Lambda anatomy

A lambda has three parts:

( parameters )  ->  body

For a Comparator<Player> there are always two parameters (the two objects being compared) and the body must produce an int.

The three common forms

// Form 1: expression body, inferred types (preferred when the body is one expression)
(a, b) -> Integer.compare(a.getGamesPlayed(), b.getGamesPlayed())

// Form 2: expression body, explicit types (use when inference is ambiguous)
(Player a, Player b) -> a.getTeam().compareTo(b.getTeam())

// Form 3: block body (required when you need more than one statement)
(a, b) -> {
    int byTeam = a.getTeam().compareTo(b.getTeam());
    if (byTeam != 0) return byTeam;
    return Integer.compare(a.getGamesPlayed(), b.getGamesPlayed());
}

How the compiler fills in the blanks

When you write:

Arrays.sort(players, (a, b) -> Integer.compare(a.getGamesPlayed(), b.getGamesPlayed()));

Java sees that Arrays.sort(Player[], Comparator<? super Player>) expects a Comparator<Player> in the second slot. The compiler therefore:

1. Concludes the lambda implements Comparator<Player> (JLS §15.27.3).
2. Assigns type Player to both a and b (JLS §15.27.1).
3. Wires the body to the compare method of that interface.

Nothing else is needed. The class wrapper, the method name, and the return type are all derived from context.

Picture: anonymous class versus lambda

ANONYMOUS CLASS                         LAMBDA
───────────────────────────────────     ──────────────────────────────
new Comparator<Player>() {              (a, b) ->
    @Override                               Integer.compare(
    public int compare(Player a,                a.getGamesPlayed(),
                       Player b) {              b.getGamesPlayed())
        return Integer.compare(
            a.getGamesPlayed(),
            b.getGamesPlayed());
    }
}

Everything to the left of the arrow in the lambda column was generated by the compiler. Only the parameter list and the body are yours to write.

Worked Example: Translate an Anonymous Class to a Lambda

The starting point

Arrays.sort(books, new Comparator<Book>() {
    @Override
    public int compare(Book a, Book b) {
        return a.getISBN().compareTo(b.getISBN());
    }
});

(Source: modernization of Bloch EJ3 Item-42)

Predict: What does the lambda version look like?

a.getISBN().compareTo(b.getISBN())

Arrays.sort(books, (a, b) -> a.getISBN().compareTo(b.getISBN()));

Arrays.sort(books, (a, b) -> a.getISBN().compareTo(b.getISBN()));

Algorithmic steps for any translation

1. Strip new Comparator<T>() { @Override public int compare( and the closing }}.
2. Keep the parameter names; drop the explicit types unless inference is ambiguous.
3. If the body is a single return expr;, replace with -> expr (no braces, no return).
4. If the body has two or more statements, keep braces and keep each return.

Quick check

Common Misconceptions

Quick check

Formal Definition and Interface Contract

Comparator<T> is a functional interface (JLS §9.8) with a single abstract method:

int compare(T o1, T o2)

Because it has exactly one abstract method, a lambda expression can satisfy it wherever a Comparator<T> is expected (JLS §15.27.3).

The full specification lives at: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Comparator.html

Bloch EJ3 Item-42 states: prefer lambdas to anonymous classes. Anonymous classes are now obsolete for functional interfaces. This is the authoritative style guidance.

The numerical contract is unchanged from the anonymous-class form:

• Negative return: first argument is less than second.
• Zero: arguments are equal for sorting purposes.
• Positive: first argument is greater than second.

Mental Model

Think of a Comparator lambda as a miniature function that takes two objects and answers the question “which one comes first?” The anonymous class was a full filing cabinet to hold that single function; the lambda is just the function, handed directly to Arrays.sort without wrapping. The compiler builds the filing cabinet in the background. What you write is only what changes from one comparator to the next: the two parameter names and the comparison expression.

Connections

Within CSCD 210/211/300: The lambda form replaces the anonymous-class Comparator and is itself replaced by method references for the common case where the body is a single method call.

Looking back: This builds on the interface mechanism from CSCD 210 (an interface defines a contract) and the anonymous-class Comparator form, which the lambda directly compresses.

Looking ahead: Method references compress the lambda further when the body is a direct delegation to an existing method. Comparator chaining with thenComparing composes multiple lambdas into a multi-key sort.

Practice

Level 1

Problem: Sort Player[] players ascending by games played using a single-line lambda passed directly to Arrays.sort.

Arrays.sort(players, (a, b) -> Integer.compare(a.getGamesPlayed(), b.getGamesPlayed()));

Level 2

Problem: Rewrite the following as a lambda:

new Comparator<Book>() {
    @Override
    public int compare(Book a, Book b) {
        return a.getISBN().compareTo(b.getISBN());
    }
}

What type does the compiler infer for a and b in your lambda, and why?

(a, b) -> a.getISBN().compareTo(b.getISBN())

Level 3

Problem: Write a block-body lambda that sorts Player[] first by team name ascending, then (as a tiebreaker) by games played ascending. The result must be passed directly to Arrays.sort.

Explain why an expression body cannot be used here.

Arrays.sort(players, (a, b) -> {
    int byTeam = a.getTeam().compareTo(b.getTeam());
    if (byTeam != 0) return byTeam;
    return Integer.compare(a.getGamesPlayed(), b.getGamesPlayed());
});

Go Deeper (optional)

None of what follows is needed to write correct lambda comparators. Read it only when you are curious about how the pieces fit into a larger picture.

How the compiler knows the types. The compiler performs “target typing” (JLS §15.27.3): it walks up the call chain to find the expected interface type, then uses that type to resolve the lambda’s parameter types and return type. This is the same inference engine that powers generic method calls. When you write Arrays.sort(players, (a, b) -> ...), the compiler sees Comparator<? super Player> in the second slot, pins T to Player, and hands both a and b the type Player without you writing it. The whole process is a form of type propagation that flows from the call site inward to the lambda body.

Lambdas are not full closures. In Python or Haskell a closure can capture and mutate variables from its enclosing scope. A Java lambda cannot: it can only refer to local variables that are effectively final, meaning the variable is never reassigned after the lambda is created. The JLS §15.27.4 specifies these capture rules precisely. The restriction exists because of the JVM’s stack discipline: a local variable lives on the stack frame of the method that created it, and that frame may be gone by the time the lambda runs. Capturing only final values sidesteps the problem cleanly. This constraint rarely matters for comparators (which typically compare fields on their two parameters rather than closing over locals), but it is the reason you cannot, for instance, accumulate a count inside a lambda variable and expect it to persist.

Where this shows up in real code. Lambda-based comparators appear in virtually every Java codebase built after 2015. Being able to read and write them fluently is a baseline expectation in industry code reviews and a routine question in technical interviews. You will encounter them immediately in any internship that touches Java.

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.