Sorting Custom Objects in Java — Comparable, Comparator, Comparator.comparing()

Two ways to sort custom objects

1. Comparable — natural ordering

• Class implements Comparable
• Override compareTo(other)
• Used by Collections.sort(list) with no extra arg
• One ordering per class
• For obvious natural order (Date, Integer, String)

2. Comparator — external ordering

• Pass to list.sort(comparator) or Collections.sort(list, comparator)
• Multiple orderings per class
• Use for context-specific sorts
• Use for third-party classes you can't modify

Java 8+ idiom — Comparator.comparing

list.sort(Comparator.comparing(Person::getName));
list.sort(Comparator.comparingInt(Person::getAge));   // no boxing

Chaining for multi-key sort

list.sort(
    Comparator.comparing(Person::getLastName)
              .thenComparing(Person::getFirstName)
              .thenComparingInt(Person::getAge)
);

Reversing

Comparator.comparingInt(Person::getAge).reversed()
Comparator.comparing(Person::getName, Comparator.reverseOrder())

Mixed direction

Comparator.comparing(Person::getName)
          .thenComparing(Comparator.comparingInt(Person::getAge).reversed())

Null handling

Comparator.nullsFirst(Comparator.comparing(Person::getName))
Comparator.comparing(Person::getName, Comparator.nullsLast(Comparator.naturalOrder()))

Common bugs

1. Integer subtraction overflow

• a.value - b.value overflows if values are extreme
• Use Integer.compare(a.value, b.value)
• Same for Long, Double, etc.

2. Comparable contract violations

• Must be reflexive, antisymmetric, transitive
• Recommended: consistent with equals
• TimSort throws IllegalArgumentException on violations

3. .reversed() is on the Comparator

• Not on the method reference
• Comparator.comparingInt(Person::getAge).reversed() ✔
• Person::getAge.reversed() ✘ (doesn't compile)

4. compareTo vs compare confusion

• Comparable.compareTo(other) — 1 param, this vs other
• Comparator.compare(a, b) — 2 params

5. Null handling

• Default comparators throw NPE on null
• Use nullsFirst / nullsLast

6. Modifying during sort

• Compared fields must be stable
• Concurrent modification → unpredictable

7. Wrong primitive comparator

• comparingInt avoids boxing
• comparing boxes int to Integer

8. == vs .equals in compareTo

• For Strings, use .compareTo() or .equals(), never ==

Comparable contract

• Reflexive: a.compareTo(a) == 0
• Antisymmetric: sgn(a.compareTo(b)) == -sgn(b.compareTo(a))
• Transitive: a > b and b > c implies a > c
• Recommended: consistent with equals (a.compareTo(b) == 0 iff a.equals(b))

Stability — TimSort is stable

• Equal elements retain original order
• Multi-pass sort works:

  • Sort by age first
  • Then sort by department — within department, age order preserved
• More common: chain comparators in one pass

Real-world examples

Employees by salary desc, then name asc

employees.sort(
    Comparator.comparingDouble(Employee::getSalary).reversed()
              .thenComparing(Employee::getName)
);

Strings by length, then alphabetically

list.sort(
    Comparator.comparingInt(String::length)
              .thenComparing(Comparator.naturalOrder())
);

Top 10 highest salary

employees.stream()
    .sorted(Comparator.comparingDouble(Employee::getSalary).reversed())
    .limit(10)
    .toList();

TreeSet / TreeMap caveat

• Use compareTo (or comparator) for membership, NOT equals
• If compareTo returns 0 for non-equal objects, they're treated as duplicates
• Inconsistency between compareTo and equals causes hard-to-find bugs
• E.g., HashSet with two equal-by-id but unequal-by-equals objects works fine; TreeSet treats them as one

For interviews

• Show Comparable for natural order
• Show Comparator.comparing chain for external
• Mention .thenComparing, .reversed, nullsFirst/Last
• Address Integer.compare for overflow safety
• Mention TimSort stability

Recommendation: Use `Comparable` when your class has an obvious universal natural ordering (e.g., dates, numeric IDs); otherwise use `Comparator` for context-specific orderings. The modern Java 8+ idiom is `Comparator.comparing(extractor)` with `.thenComparing(...)` for multi-key sort and `.reversed()` for descending; use `comparingInt`/`comparingLong`/`comparingDouble` to avoid boxing for primitive keys. Always use `Integer.compare(a, b)` instead of a - b to avoid integer overflow when values are extreme. For null handling, wrap with `Comparator.nullsFirst(...)` or `Comparator.nullsLast(...)`. The Comparable contract must be reflexive, antisymmetric, and transitive, and ideally consistent with `equals` — inconsistency causes weird behavior in TreeSet/TreeMap. TimSort (Java's default for object sort) is stable, so multi-pass sorting works, but prefer chaining comparators in one pass. Avoid common bugs: subtraction overflow, forgetting `.reversed()` is on Comparator, mixing up `compareTo` (one param) and `compare` (two params), and modifying objects during sort. The mental model: Comparable = one natural order baked into the class; Comparator = pluggable orderings via factory + chain. For complex orderings, build them declaratively with Comparator.comparing(...).thenComparing(...).reversed() — the chain reads top-to-bottom and is far cleaner than handwritten lambdas.