How to Sort a List of Objects by Property in Java

Q: How do I sort an ArrayList of objects before Java 8?

Pass Collections.sort an anonymous Comparator: Collections.sort(people, new Comparator () { @Override public int compare(Person a, Person b) { return a.getName().compareTo(b.getName()); } });. It still compiles and works. Since Java 8 the same sort is people.sort(Comparator.comparing(Person::getName)), and Collections.sort(list, c) simply calls list.sort(c).

Q: How do I sort a list of objects in descending order?

Call .reversed() on the comparator: people.sort(Comparator.comparingInt(Person::age).reversed()). To reverse one key and not the rest, pass Comparator.reverseOrder() as the key comparator: Comparator.comparing(Person::name, Comparator.reverseOrder()). Collections.reverseOrder(cmp) also reverses a comparator. Remember that .reversed() at the end of a thenComparing chain reverses every key in it.

Q: Is List.sort stable in Java?

Yes. The List.sort and Collections.sort documentation guarantees a stable sort: elements that compare equal keep their original relative order. The implementation is TimSort (for objects), which is also fast on lists that are already partly sorted. Stream.sorted is stable for ordered streams, such as a stream over a List. Stability is what lets thenComparing chains and repeated sorts behave predictably on ties.

Q: What does "Comparison method violates its general contract!" mean?

TimSort throws java.lang.IllegalArgumentException: Comparison method violates its general contract! when it notices that your comparator contradicts itself, for example saying a a - b triggers it for some inputs. Replace hand-written comparisons with Integer.compare or Comparator.comparingInt.

Q: Should I implement Comparable or use a Comparator?

Implement Comparable only when the type has one natural order that every caller would expect, such as a version number or an amount of money; then Collections.sort(list), TreeSet and Collections.max work without arguments. For everything else, and for any type you do not own, pass a Comparator: you can have as many as you like, one per sort order. A compareTo can itself delegate to a static final Comparator built with comparingInt(...).thenComparing(...). Sorting a type that is not Comparable with no comparator fails: Collections.sort(list) does not compile, and list.sort(null) compiles but throws java.lang.ClassCastException: class Main$Person cannot be cast to class java.lang.Comparable.

Quick answer

Pass List.sort a comparator built from the property: people.sort(Comparator.comparing(Person::name)). Use Comparator.comparingInt(Person::age) for an int field, add .reversed() for descending order and .thenComparing(...) for a tie-breaker. For a sorted copy that leaves the list alone, use people.stream().sorted(comparator).toList() (Java 16+).

A List<Person> has no idea how one Person compares to another, so you tell it with a Comparator<Person>: a function that takes two elements and returns a negative number, zero or a positive number. Since Java 8 you rarely write that function yourself. The static factories on Comparator build it from the property you want to sort by, and they chain for descending order, tie-breaks, case-insensitive text and null values. This page covers those, the Comparable interface for a type's built-in order, sorting a copy instead of the list itself, and the subtraction comparator that still shows up in old answers and overflows. The data types are records (Java 16+). Each example runs on this page: hit Run, then edit the code and run it again.

1list.sort(Comparator.comparing(...))Recommended

Comparator.comparing(Person::name) takes a key extractor, a function that reads the property, and returns a comparator that compares the keys. The key can be any Comparable type: String, Integer, LocalDate, BigDecimal, an enum. For primitive fields, comparingInt, comparingLong and comparingDouble compare the raw values instead of boxing each one into an Integer or Double on every comparison. List.sort reorders the list in place.

Main.java

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

public class Main {
    record Person(String name, int age, double height, LocalDate joined) {}

    public static void main(String[] args) {
        List<Person> people = new ArrayList<>(List.of(
            new Person("Grace", 45, 1.68, LocalDate.of(2021, 3, 14)),
            new Person("Ada", 36, 1.65, LocalDate.of(2019, 11, 2)),
            new Person("Linus", 28, 1.80, LocalDate.of(2023, 6, 30)),
            new Person("Barbara", 52, 1.72, LocalDate.of(2018, 1, 9))
        ));

        // By a String property: pass the accessor as a method reference
        people.sort(Comparator.comparing(Person::name));
        System.out.println(names(people));
        System.out.println(people.get(0));

        // By an int property: comparingInt compares plain ints, no boxing
        people.sort(Comparator.comparingInt(Person::age));
        System.out.println(names(people));

        // Descending: .reversed() flips any comparator
        people.sort(Comparator.comparingDouble(Person::height).reversed());
        System.out.println(names(people));

        // By a LocalDate: it is Comparable, so comparing() works as is
        people.sort(Comparator.comparing(Person::joined));
        for (Person p : people) {
            System.out.println(p.joined() + " " + p.name());
        }
    }

    static List<String> names(List<Person> people) {
        return people.stream().map(Person::name).toList();
    }
}

Output

Prints [Ada, Barbara, Grace, Linus] and the first record, Person[name=Ada, age=36, height=1.65, joined=2019-11-02]. Then [Linus, Ada, Grace, Barbara] youngest first, [Linus, Barbara, Grace, Ada] tallest first, and the four join dates from 2018-01-09 Barbara to 2023-06-30 Linus. With a class instead of a record the method reference is Person::getName. The key extractor can be any lambda, so Comparator.comparing(c -> c.address().city()) sorts by a nested property. The long-hand equivalent of the first sort is people.sort((a, b) -> a.name().compareTo(b.name())), which is what many older answers show.

2Multiple fields: thenComparing and reversed()

thenComparing adds a tie-breaker: the second key is only consulted when the first one compares equal. There are primitive versions too (thenComparingInt and friends), and a two-argument form, thenComparing(key, comparator), that sorts just that key in its own order. The one thing to watch is where .reversed() goes: it reverses the whole comparator it is called on, which includes every key chained before it.

Main.java

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

public class Main {
    record Player(String name, String team, int score) {}

    public static void main(String[] args) {
        List<Player> players = new ArrayList<>(List.of(
            new Player("dana", "red", 90),
            new Player("alice", "blue", 90),
            new Player("carol", "red", 70),
            new Player("bob", "blue", 70)
        ));

        // Score high to low, then name A-Z when the scores tie
        players.sort(Comparator.comparingInt(Player::score).reversed()
                .thenComparing(Player::name));
        for (Player p : players) {
            System.out.println(p.score() + " " + p.name());
        }

        System.out.println("--");

        // Team A-Z, then score high to low: reverse only the second key
        players.sort(Comparator.comparing(Player::team)
                .thenComparing(Player::score, Comparator.reverseOrder()));
        for (Player p : players) {
            System.out.println(p.team() + " " + p.score() + " " + p.name());
        }

        System.out.println("--");

        // Careful: reversed() at the end flips the whole chain before it
        players.sort(Comparator.comparing(Player::team)
                .thenComparing(Player::name)
                .reversed());
        for (Player p : players) {
            System.out.println(p.team() + " " + p.name());
        }
    }
}

Output

The first block prints 90 alice, 90 dana, 70 bob, 70 carol: the .reversed() sits right after the score key, so only the score is descending. The second prints blue 90 alice, blue 70 bob, red 90 dana, red 70 carol. The last prints red dana, red carol, blue bob, blue alice: both the team and the name came out descending, because the trailing .reversed() applied to the whole chain. List.sort is guaranteed stable, so elements that compare equal on every key keep the order they already had.

3Case-insensitive text and null values

Two things break a plain comparing(...) on real data. String's natural order compares character codes, so every uppercase letter sorts before every lowercase one. And a null property makes the comparator throw a NullPointerException. Both have a fix in the same place: the second argument of comparing, which says how to compare the extracted keys.

Main.java

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

public class Main {
    record Contact(String name, String city) {}

    public static void main(String[] args) {
        List<Contact> contacts = new ArrayList<>(Arrays.asList(
            new Contact("bob", "Oslo"),
            new Contact("Alice", null),
            new Contact("carol", "Berlin"),
            new Contact("Dave", "Austin")
        ));

        // String's natural order is by char code: every capital before every lowercase
        contacts.sort(Comparator.comparing(Contact::name));
        System.out.println(contacts.stream().map(Contact::name).toList());

        // Case-insensitive: pass a second comparator for the key
        contacts.sort(Comparator.comparing(Contact::name, String.CASE_INSENSITIVE_ORDER));
        System.out.println(contacts.stream().map(Contact::name).toList());

        // A null property value makes the plain comparator throw
        try {
            contacts.sort(Comparator.comparing(Contact::city));
        } catch (NullPointerException e) {
            System.out.println("comparing(Contact::city) threw NullPointerException");
        }

        // nullsLast / nullsFirst wrap the key comparator and place nulls explicitly
        contacts.sort(Comparator.comparing(Contact::city,
                Comparator.nullsLast(Comparator.naturalOrder())));
        for (Contact c : contacts) {
            System.out.println(c.city() + " " + c.name());
        }

        // A null element in the list: wrap the whole comparator instead
        List<Contact> withNull = new ArrayList<>(contacts);
        withNull.add(null);
        withNull.sort(Comparator.nullsFirst(
                Comparator.comparing(Contact::name, String.CASE_INSENSITIVE_ORDER)));
        System.out.println(withNull.get(0) + ", then " + withNull.get(1).name());
    }
}

Output

Prints [Alice, Dave, bob, carol] with the natural order and [Alice, bob, carol, Dave] case-insensitively, then comparing(Contact::city) threw NullPointerException. With nullsLast the cities print Austin Dave, Berlin carol, Oslo bob, null Alice, and the last line is null, then Alice. Note the two positions: nullsLast inside comparing handles a null property, nullsFirst around the whole comparator handles a null element. CASE_INSENSITIVE_ORDER only folds case; for accents and language rules, pass a java.text.Collator such as Collator.getInstance(Locale.FRENCH) as the key comparator instead.

4Comparable (natural order) and the subtraction bug

If a type has one obvious order, such as version numbers or money, make it implement Comparable<T> and put the order in compareTo. Then Collections.sort(list), list.sort(null), TreeSet, Collections.max and Comparator.reverseOrder() all use it without being told how. Records do not implement Comparable on their own. When you write compareTo or a compare lambda by hand, compare with Integer.compare, never by subtracting: the subtraction can overflow and flip the sign.

Main.java

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

public class Main {
    // Comparable gives the type one built-in "natural" order
    record Version(int major, int minor) implements Comparable<Version> {
        private static final Comparator<Version> ORDER =
                Comparator.comparingInt(Version::major).thenComparingInt(Version::minor);

        @Override
        public int compareTo(Version other) {
            return ORDER.compare(this, other);
        }

        @Override
        public String toString() {
            return major + "." + minor;
        }
    }

    record Account(String id, int balance) {}

    public static void main(String[] args) {
        List<Version> versions = new ArrayList<>(List.of(
            new Version(2, 0), new Version(1, 10), new Version(1, 2)
        ));

        // No comparator needed: these all use compareTo
        Collections.sort(versions);
        System.out.println(versions);
        versions.sort(Comparator.reverseOrder());
        System.out.println(versions);
        System.out.println(Collections.max(versions));

        // The classic bug: a comparator that subtracts can overflow
        List<Account> accounts = new ArrayList<>(List.of(
            new Account("A", 2_000_000_000),
            new Account("B", -2_000_000_000),
            new Account("C", 0)
        ));
        accounts.sort((a, b) -> a.balance() - b.balance());
        System.out.println(accounts.stream().map(Account::id).toList());
        System.out.println(2_000_000_000 - (-2_000_000_000));

        // Integer.compare (or comparingInt) never overflows
        accounts.sort((a, b) -> Integer.compare(a.balance(), b.balance()));
        System.out.println(accounts.stream().map(Account::id).toList());
    }
}

Output

Prints [1.2, 1.10, 2.0], [2.0, 1.10, 1.2] and 2.0: numeric order, so 1.10 comes after 1.2, which a string sort would get wrong. The subtraction comparator leaves the accounts as [A, B, C], with two billion before minus two billion, because 2_000_000_000 - (-2_000_000_000) is -294967296 in int arithmetic, so it reported A as smaller than B. Integer.compare gives the correct [B, C, A]. Building compareTo from a static final Comparator, as Version does, avoids hand-written comparisons entirely. Keep natural order consistent with equals where you can: a TreeSet treats two elements that compare as 0 as duplicates.

5Sort a copy: stream().sorted().toList()

list.sort and Collections.sort change the list they are given. When the original order still matters, or the list is unmodifiable (List.of, Stream.toList(), a Collections.unmodifiableList view), sort a copy. A stream does it in one expression, and Stream.toList() (Java 16+) collects the result. For the same order backwards, Java 21 added List.reversed(), a reverse-order view that copies and sorts nothing.

Main.java

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

public class Main {
    record Book(String title, int year) {}

    public static void main(String[] args) {
        List<Book> books = List.of(
            new Book("Dune", 1965),
            new Book("Neuromancer", 1984),
            new Book("Foundation", 1951)
        );

        // stream().sorted() builds a new list; the source keeps its order (toList is Java 16+)
        List<Book> byYear = books.stream()
                .sorted(Comparator.comparingInt(Book::year))
                .toList();
        System.out.println(titles(byYear));
        System.out.println(titles(books));

        // List.of is unmodifiable, so sorting it in place throws
        try {
            books.sort(Comparator.comparing(Book::title));
        } catch (UnsupportedOperationException e) {
            System.out.println("sort failed: " + e);
        }

        // Or copy into an ArrayList first, then sort the copy
        List<Book> byTitle = new ArrayList<>(books);
        byTitle.sort(Comparator.comparing(Book::title));
        System.out.println(titles(byTitle));

        // Java 21+: reversed() is a reverse-order view, no copy and no re-sort
        System.out.println(titles(byYear.reversed()));
    }

    static List<String> titles(List<Book> books) {
        return books.stream().map(Book::title).toList();
    }
}

Output

Prints [Foundation, Dune, Neuromancer], then the untouched source [Dune, Neuromancer, Foundation], then sort failed: java.lang.UnsupportedOperationException, then [Dune, Foundation, Neuromancer] from the copy and [Neuromancer, Dune, Foundation] from the reversed view. The list from toList() is unmodifiable too; on Java 8 to 15, or when you need a list you can add to, collect with Collectors.toList() or new ArrayList<>(...). Both approaches copy only the list: the records inside are the same objects. Building the list in the first place is covered in initialize a list in one line.

6Which should you use?

Comparator	Needs	Best for
list.sort(Comparator.comparing(Person::name))	Java 8+	Strings, dates, any Comparable property: the default
Comparator.comparingInt(Person::age)	Java 8+	int, long and double properties without boxing
.reversed() / thenComparing(key, Comparator.reverseOrder())	Java 8+	Descending order, for the whole chain or one key
.thenComparing(Person::name)	Java 8+	Tie-breaks, sorting by several fields
comparing(key, String.CASE_INSENSITIVE_ORDER)	Java 8+	Names and titles people read
comparing(key, Comparator.nullsLast(Comparator.naturalOrder()))	Java 8+	Properties that can be null
implements Comparable<T> + Collections.sort(list)	Any version	Types with one obvious order (versions, money)
list.stream().sorted(cmp).toList()	Java 16+	A sorted copy; the source stays as it was
(a, b) -> a.age() - b.age()	Avoid	Nothing: it overflows; use Integer.compare or comparingInt

Frequently asked questions

How do I sort an ArrayList of objects before Java 8?

Pass Collections.sort an anonymous Comparator: Collections.sort(people, new Comparator<Person>() { @Override public int compare(Person a, Person b) { return a.getName().compareTo(b.getName()); } });. It still compiles and works. Since Java 8 the same sort is people.sort(Comparator.comparing(Person::getName)), and Collections.sort(list, c) simply calls list.sort(c).

How do I sort a list of objects in descending order?

Call .reversed() on the comparator: people.sort(Comparator.comparingInt(Person::age).reversed()). To reverse one key and not the rest, pass Comparator.reverseOrder() as the key comparator: Comparator.comparing(Person::name, Comparator.reverseOrder()). Collections.reverseOrder(cmp) also reverses a comparator. Remember that .reversed() at the end of a thenComparing chain reverses every key in it.

Why does Comparator.comparing(p -> p.name()).reversed() not compile?

Java infers the lambda parameter type from the target type, but .reversed() is called on the result of comparing(...) first, so there is no target type yet and p becomes Object. javac reports error: cannot find symbol, symbol: method name(), location: variable p of type java.lang.Object. Use a method reference (Comparator.comparing(Person::name).reversed()), type the parameter ((Person p) -> p.name()), or add a type witness (Comparator.<Person, String>comparing(p -> p.name())). Without .reversed(), people.sort(Comparator.comparing(p -> p.name())) compiles fine.

Is List.sort stable in Java?

Yes. The List.sort and Collections.sort documentation guarantees a stable sort: elements that compare equal keep their original relative order. The implementation is TimSort (for objects), which is also fast on lists that are already partly sorted. Stream.sorted is stable for ordered streams, such as a stream over a List. Stability is what lets thenComparing chains and repeated sorts behave predictably on ties.

What does "Comparison method violates its general contract!" mean?

TimSort throws java.lang.IllegalArgumentException: Comparison method violates its general contract! when it notices that your comparator contradicts itself, for example saying a < b, b < c and c < a. The usual causes are a subtracting comparator that overflows, a comparator that reads mutable or random state, or one that mishandles nulls or NaN. Sorting 5000 random ints with (a, b) -> a - b triggers it for some inputs. Replace hand-written comparisons with Integer.compare or Comparator.comparingInt.

Should I implement Comparable or use a Comparator?

Implement Comparable only when the type has one natural order that every caller would expect, such as a version number or an amount of money; then Collections.sort(list), TreeSet and Collections.max work without arguments. For everything else, and for any type you do not own, pass a Comparator: you can have as many as you like, one per sort order. A compareTo can itself delegate to a static final Comparator built with comparingInt(...).thenComparing(...). Sorting a type that is not Comparable with no comparator fails: Collections.sort(list) does not compile, and list.sort(null) compiles but throws java.lang.ClassCastException: class Main$Person cannot be cast to class java.lang.Comparable.

Run it yourself

Open any of these in the full Java editor: tweak, run, and share.

Java playground