Rewrite (a, b) -> a.compareTo(b) as String::compareTo

• An unbound two-argument reference Type::instanceMethod maps the first parameter to the receiver and the second to the method argument.
• String::compareTo satisfies Comparator because compare(a, b) calls a.compareTo(b).
• The bound form someString::compareTo fixes the receiver and leaves only the argument.
• For natural ordering, Comparator.naturalOrder() is clearer and supports null layering.

How does a two-argument method reference work?

The compiler maps the first lambda parameter to the method receiver and the remaining parameters to the method's arguments.

package com.bank.core;

import java.util.*;

public class CompareToRef {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>(List.of(
            "Priya", "Amit", "Rajesh", "Kavita"));

        // Lambda
        names.sort((a, b) -> a.compareTo(b));

        // Method reference (equivalent)
        names.sort(String::compareTo);

        System.out.println(names);
    }
}

[Amit, Kavita, Priya, Rajesh]

How is unbound different from bound?

| Form | Syntax | Receiver | Arguments |
|---|---|---|---|
| Unbound | String::compareTo | Supplied as first param | Second param |
| Bound | "Rajesh"::compareTo | Fixed to "Rajesh" | Only param |

// Unbound: both arguments come from the comparator
Comparator<String> unbound = String::compareTo;
// compare("Priya", "Amit") → "Priya".compareTo("Amit")

// Bound: receiver is fixed, only one argument needed
java.util.function.ToIntFunction<String> bound = "Rajesh"::compareTo;
// applyAsInt("Amit") → "Rajesh".compareTo("Amit")

When should you use Comparator.naturalOrder() instead?

For natural ordering, Comparator.naturalOrder() states the intent more clearly and supports null layering.

// All three are equivalent for non-null strings:
names.sort(String::compareTo);
names.sort(Comparator.naturalOrder());
names.sort((a, b) -> a.compareTo(b));

// But only naturalOrder supports null handling:
names.sort(Comparator.nullsFirst(Comparator.naturalOrder()));

What are common mistakes?

Mistake: confusing which parameter is the receiver.

// String::compareTo means: first.compareTo(second)
// NOT: second.compareTo(first)
// So this sorts ascending (natural order), not descending.
names.sort(String::compareTo);  // ascending

// For descending, use reversed():
names.sort(Comparator.reverseOrder());

What about case-insensitive comparison with method references?

// Case-insensitive sort using an unbound method reference
names.sort(String::compareToIgnoreCase);

// Equivalent lambda
names.sort((a, b) -> a.compareToIgnoreCase(b));

What about using method references with custom objects?

The same pattern applies to any class with a compareTo method.

import java.math.BigDecimal;

List<BigDecimal> balances = new java.util.ArrayList<>(List.of(
    new BigDecimal("95000"), new BigDecimal("120000"), new BigDecimal("78000")));

balances.sort(BigDecimal::compareTo); // ascending by value

What should a senior engineer know?

• The unbound form works for any instance method on the type that takes the right number of remaining parameters.
• String::compareTo is natural ascending order. For descending, use Comparator.reverseOrder().
• Method references read best when the method name conveys the intent; compareTo is well-known enough to be clear.

What are common interview follow-up questions?

• "How do you sort case-insensitively?" Use String.CASE_INSENSITIVE_ORDER or String::compareToIgnoreCase.
• "What is the difference between Comparator.naturalOrder() and String::compareTo?" Functionally identical, but naturalOrder() is more intention-revealing.
• "Can you use this with non-Comparable types?" No; compareTo requires the type to implement Comparable.