Immutability & Defensive Copying

An immutable object is one whose state can never change after it is constructed, and defensive copying is how you stop mutable inputs and outputs from quietly breaking that guarantee.

Learn Immutability & Defensive Copying in our free Java course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick…

Part of the free Java course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

You should be comfortable with classes , the final keyword and access modifiers , and the Collections . Knowing records helps — they are immutable carriers by design.

💡 Analogy: An immutable object is like a signed, witnessed contract . Once it's signed you can't scribble new terms onto it — if you want different terms you draft a whole new contract. That's why everyone can be handed a copy without worrying someone will alter it behind their back. Defensive copying is the lawyer photocopying any attachments you bring, so that even if you later edit your attachment, the signed version stays exactly as agreed.

Without that photocopy step, your "immutable" object is only as safe as the mutable list someone handed you — and they can keep editing it from outside.

For a class with only primitive or already-immutable fields, immutability is easy: make the class final , make every field private final , set them in the constructor, and provide no setters . Any "change" returns a brand-new object — exactly how String and BigDecimal work.

The trouble starts when a field is mutable , like a List . If the constructor just stores the caller's list and the getter hands it straight back, your object isn't immutable at all — outside code can mutate it through the reference it still holds or through the getter.

Copy on the way in and on the way out . List.copyOf(members) makes an independent, unmodifiable snapshot in the constructor, so later edits to the caller's list don't touch you. Because that copy is already read-only, the getter can return it directly — callers can read but never mutate.

A record is the natural home for immutable data — final fields, no setters, free equals / hashCode . But it is only shallowly immutable: a mutable component like a List can still be changed unless you defensively copy it in the compact constructor .

Answer: no. final stops you reassigning the field to a different list, but you can still add / remove from the list it points to. Use List.copyOf for content immutability.

Answer: List.copyOf takes a true snapshot, so it is unaffected. Collections.unmodifiableList is just a view — if the underlying list changes, the view shows the change.

Answer: because no thread can change their state, there are no races to guard against — you can share one instance across threads with no locks at all.

🎯 YOUR TURN — Immutable Money

Give Money no setters and a plus that returns a new instance, leaving both operands unchanged.

🧩 MINI-CHALLENGE — Defensive Route

Build an immutable Route whose stops are defensively copied so neither the input list nor the accessor can alter it.

You can now build a properly immutable class — final, no setters, "change" via new instances — spot the leak when a mutable field is stored or returned directly, plug it with defensive copies and List.copyOf , and harden a record's mutable components in its compact constructor.

Next up: The Builder Pattern — constructing complex immutable objects step by step without a telescoping constructor.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary