How Do You Build an Immutable Class?

A class is immutable if its state cannot change after construction — if, once created, it is guaranteed to be the same for the whole of its life. That is stronger than merely having no setters, and the rules are specific.

First, the class must be final or its state-providing methods must be final. Otherwise a subclass could override a getter and change the behaviour, so a caller holding the parent type would get different values depending on the runtime type. Second, all the fields must be final, which is what the compiler uses to guarantee the values are published safely to other threads. Third, the constructor must set the fields and must not leak the reference to a partially built object — meaning no calling an overridable method from the constructor.

Fourth, and this is the one people forget, the fields must not refer to mutable objects unless those references are defensively copied. A final field holding a mutable List is not immutable, because anyone holding the List can change what the object contains.

Two consequences follow. An immutable object needs no synchronisation when shared between threads, because there is nothing to protect. And because its hash code cannot change, it is safe to use as a map key and to cache inside a hash-based set.

The shape is straightforward: a final class, final fields, a constructor that assigns them, accessors that return the values, and a defensive copy for anything mutable.

import java.util.List;

public class Main {
    public static void main(String[] args) {
        Money m = new Money(1050, "GBP");
        System.out.println("money   : " + m);
        System.out.println("pence   : " + m.pence());
        System.out.println("pounds  : " + m.asPounds());

        // The list is unmodifiable, so the object cannot be mutated through it.
        System.out.println("items   : " + m.items());
        try {
            m.items().add("tampering");
        } catch (UnsupportedOperationException e) {
            System.out.println("the list is unmodifiable");
        }
    }
}

final class Money {
    private final int pence;
    private final String currency;
    private final List<String> items;

    Money(int pence, String currency) {
        this.pence = pence;
        this.currency = currency;
        this.items = List.of();
    }

    int pence() {
        return pence;
    }

    double asPounds() {
        return pence / 100.0;
    }

    List<String> items() {
        return items;
    }

    @Override
    public String toString() {
        return pence + " " + currency;
    }
}

The output shows the defensive copy at work. The list handed back by the accessor is unmodifiable, so the attempt to add to it throws rather than silently changing the object.

There are two flavours of defensive copy and the choice matters. Copy on input — copy the collection in the constructor, as the example does — so the object owns its state and no later change to the caller's list can affect it. Copy on output — return a fresh copy from the accessor — so the caller cannot change the object's state through the reference it was given. For a truly immutable object you want the copy on input, because then the accessor can hand out the same unmodifiable list every time without allocating again.

Two more practical points. Validate in the constructor and throw on bad input, because an immutable object that is invalid can never be corrected. And when a class is genuinely just data, a record gives you all of this for free, with the generated equals, hashCode and toString already correct.

The benefits are real and they compound. An immutable object needs no synchronisation when shared between threads, because there is no state to protect — publication is safe by construction, since final fields are guaranteed to be visible once the object is safely published. It is safe as a map key, because its hash code cannot change and so it cannot become unreachable in the map. It is predictable, because the value at the moment you read it can never change underneath you. And it is trivially thread safe to pass around, which is what makes it the natural currency of concurrent code.

It also makes the class far easier to reason about. If every object you hold is immutable, then a whole layer of bugs — the ones where a field changes between two lines of your code — simply cannot happen.

Where it bites is in three places. Construction cost. An immutable object with many parts may need a builder, because a constructor with twenty arguments is unreadable. Identity. Sometimes you genuinely want an object whose identity matters rather than its value — a session, an order in progress, an entity with a lifecycle — and making that immutable fights the domain. Performance. Copying a large collection defensively on every construction or every read is not free, and for a big structure you may decide that the safety is not worth it.

The pragmatic advice is to make values immutable and leave entities mutable, and to lean on the language for it: records give you immutable data classes without the boilerplate, and when you do need a mutable one, keeping the mutable state in one clearly marked place is much better than scattering it.