Immutability: final, unmodifiable views, and defensive copies

An immutable object is one whose observable state can never change after construction. Immutable values are safe to share between threads without locks, safe as HashMap keys, and safe to cache and hand out — nobody can change them behind your back. String, Integer, LocalDate and BigDecimal are all immutable.

final is about the variable, not the object

final List<String> names = new ArrayList<>(); means names can never point at a different list. The list itself is as mutable as ever: names.add("x") compiles and works. final on every field is necessary for an immutable class, not sufficient.

A view is not a copy

Collections.unmodifiableList(list) returns a read-only view: you cannot modify through it, but it reads straight through to the original list, so anyone holding the original can still change what the view shows. List.copyOf(list) (and List.of, Set.copyOf, Map.copyOf) makes an unmodifiable copy that nothing can change. The copies also reject null elements.

1import java.util.*;2 3public class Solution {4    public static List<String> describe() {5        List<String> source = new ArrayList<>(List.of("a", "b"));6        final List<String> view = Collections.unmodifiableList(source);7        final List<String> copy = List.copyOf(source);8 9        source.add("c");   // change the original after the fact10 11        List<String> out = new ArrayList<>();12        out.add("view=" + view + " copy=" + copy);13        try {14            view.add("d");15        } catch (UnsupportedOperationException e) {16            out.add("view.add: UnsupportedOperationException");17        }18        try {19            List.copyOf(Arrays.asList("x", null));20        } catch (NullPointerException e) {21            out.add("copyOf with a null: NullPointerException");22        }23        return out;24    }25}

Records are only shallowly immutable

A record's fields are final, but a component of type List still refers to whatever list the caller passed in. If the caller keeps that list and changes it, the record changes too — and so does its hashCode. The fix is a defensive copy in the compact constructor:

1import java.util.*;2 3public class Solution {4    record LeakyTeam(String name, List<String> members) {}5 6    record Team(String name, List<String> members) {7        Team {8            members = List.copyOf(members);   // defensive copy9        }10    }11 12    public static List<String> describe() {13        List<String> people = new ArrayList<>(List.of("ana", "bo"));14        LeakyTeam leaky = new LeakyTeam("core", people);15        Team safe = new Team("core", people);16        int hashBefore = leaky.hashCode();17 18        people.add("cy");                      // the caller keeps editing19 20        return List.of(21            "leaky=" + leaky.members() + " hashChanged=" + (hashBefore != leaky.hashCode()),22            "safe=" + safe.members());23    }24}

The recipe for an immutable class: make it final (or a record), make every field private final, copy mutable inputs on the way in, never hand out a mutable internal object on the way out (return the unmodifiable copy, or a fresh copy), and provide no setters. To "change" an immutable value, return a new one — withPrice(...), plusDays(...), toUpperCase().

Common mistakes

• Assuming final fields make an object immutable; a final array or list field can still be filled and emptied.
• Returning Collections.unmodifiableList(internal) from a constructor argument the caller still owns — the caller can change it through the original reference, as the first example shows.
• Calling List.of(...) or List.copyOf(...) on data that may contain null; both throw NullPointerException.
• "Updating" an immutable value and ignoring the result: date.plusDays(1); on its own does nothing.

What interviewers ask

• How do you make a class immutable? Final class, private final fields, no setters, defensive copies of mutable inputs and outputs, and changes expressed as methods that return new instances.
• Is a record immutable? Shallowly: its fields cannot be reassigned, but mutable components (lists, arrays, dates from old APIs) need a copy in the compact constructor.