Designing immutable objects

Immutable objects are a favourite interview topic because the beginner answer is short, but the senior answer touches design, collections, records and the Java Memory Model. Many candidates say "make fields final" and stop there. That is not enough if a Date, array or List reference leaks.

For this lesson, we'll focus on the practical recipe: final class, private final fields, no setters, defensive copies on the way in and out, records as shallow immutable carriers, collection wrappers, safe publication and builder or wither patterns.

01Picture it first: a museum display case

Think of an immutable object as a museum display case. The artifact can be seen from outside, but visitors never get a key to the case. If the curator accepts a borrowed artifact in a cardboard box and leaves the box with the lender, the lender can swap it later. Defensive copies are the curator making their own sealed copy before the display opens.

The figure below shows the whole contract: build once, seal the fields, then only share values that cannot mutate the inside.

Fig. 1

Immutable objects are built once from copied inputs, hold private final state and expose only safe outputs instead of leaking the original mutable pieces

That boundary is the thing interviewers listen for. private final protects the reference from being reassigned inside the class. It does not freeze the object that reference points to.

02Building an immutable class under the hood

import java.util.*;

final class Invoice {
    private final String id;
    private final Date issuedAt;
    private final List<String> lineItems;

    Invoice(String id, Date issuedAt, List<String> lineItems) {
        this.id = Objects.requireNonNull(id);
        this.issuedAt = Objects.requireNonNull(issuedAt);
        this.lineItems = Objects.requireNonNull(lineItems);
    }

    Date issuedAt() { return issuedAt; }
    List<String> lineItems() { return lineItems; }
}

The Date and List references are final, but the objects are mutable. The caller can keep the original list and add a row after construction. The getter also returns the same Date, so another caller can call setTime and rewrite your invoice timestamp.

Here's how I'd write it in Java 21.

import java.time.Instant;
import java.util.*;

final class Invoice {
    private final String id;
    private final Instant issuedAt;
    private final List<String> lineItems;

    Invoice(String id, Instant issuedAt, List<String> lineItems) {
        this.id = Objects.requireNonNull(id);
        this.issuedAt = Objects.requireNonNull(issuedAt);
        this.lineItems = List.copyOf(lineItems);
    }

    String id() { return id; }
    Instant issuedAt() { return issuedAt; }
    List<String> lineItems() { return lineItems; }
}

Notice four things:

• The class is final. A subclass cannot add mutable state and still pretend to follow the same contract.
• Fields are private final. No caller can see the fields directly, and the constructor assigns each one once.
• Instant is immutable. Prefer immutable JDK types over legacy mutable types like Date.
• List.copyOf is a snapshot. Later changes to the input list do not affect the invoice.

The defensive-copy decision tree below is the one I use in code review.

Fig. 2

Decision tree for immutable fields: immutable values can be stored directly, mutable inputs need a copy, collections need List.copyOf and arrays need clone or a list conversion

List.copyOf versus Collections.unmodifiableList