An immutable class is one whose objects, once constructed, never change - not a field, not the contents of anything that field points to, nothing. String, Integer, LocalDate, and BigDecimal are all immutable: every "modifying" method on them - toUpperCase(), plus(), withYear() - returns a brand-new object and leaves the original untouched. The appeal is not abstract. An object that cannot change cannot be corrupted by another part of the program, cannot be caught mid-update by a second thread, and cannot have its hashCode() quietly go stale after it has been used as a map key. Building one correctly takes more than writing final on every field - and exactly where the extra work is needed is what most of this article is about.

What Is an Immutable Class?

A class is immutable when every object of that class has the same observable state for its entire lifetime - from the moment its constructor finishes to the moment it is garbage collected. This is a stronger statement than "the fields are final": a final field cannot be reassigned, but if it refers to a mutable object - a List, a Date, an array - that object's contents can still change, which means the "immutable" object's observable state changes too.

final class Coupon {
    private final String code;
    private final double discountPercent;
    private final LocalDate expiryDate;
    // constructor sets all three, once; only accessor methods after that
}

Basic Overview - The Rules That Make a Class Immutable

RULE 1 - DON'T PROVIDE MUTATOR METHODS
  Fresher view  : no setCode(), no setDiscountPercent() - only getters
  Deeper view   : this includes methods that LOOK read-only but mutate
                  something reachable from a field - e.g., a method
                  that calls .add() on a field that is a List

RULE 2 - MAKE EVERY FIELD private AND final
  Fresher view  : every field is set once, in the constructor, and
                  never reassigned anywhere else
  Deeper view   : 'final' here prevents REASSIGNING the field - it
                  says nothing about whether the OBJECT the field
                  refers to can itself be mutated (Rules 4 and 5 cover that)

RULE 3 - MAKE THE CLASS final (OR PREVENT SUBCLASSING ANOTHER WAY)
  Fresher view  : 'final class Coupon' - no one can extend Coupon
  Deeper view   : an immutable class's guarantees are about its OWN
                  code - a subclass could add mutable state, or
                  override a method to behave differently, breaking
                  the guarantee for anyone holding a Coupon reference
                  that is secretly a mutable subclass

RULE 4 - DEFENSIVE COPY ON INPUT
  Fresher view  : if the constructor receives a List, Date, or array,
                  copy it - don't just store the reference you were given
  Deeper view   : without this, the CALLER still holds a reference to
                  the same object - and can mutate it AFTER construction,
                  changing the "immutable" object's state from outside

RULE 5 - DEFENSIVE COPY ON OUTPUT
  Fresher view  : if a getter would return a List, Date, or array,
                  return a copy (or an unmodifiable view of a copy) -
                  not the internal field itself
  Deeper view   : without this, ANY caller of the getter receives a
                  reference to the SAME internal object - and can
                  mutate it, changing the object's state from outside,
                  through a method that looks like a harmless read

A fresher can start with rules 1 through 3 - no setters, private final fields, final class - and that alone covers any class whose fields are all primitives, String, or other immutable types (which is a large fraction of real "data holder" classes). Rules 4 and 5 are where this topic stops being mechanical: they apply only when a field's type is itself mutable, they are easy to forget precisely because the class still looks correct without them, and they are the single most common gap between "I made the fields final" and "this class is actually immutable."

Why Immutable Classes Matter

The thread-safety argument is the one most often quoted, and it is real: an object with no mutable state has nothing for two threads to race over. No synchronized, no lock, no volatile - reading an immutable object from any thread, at any time, always sees the same values it had at construction, because there is no other state it could have.

The less-discussed argument is what immutability does for single-threaded correctness. An immutable object can be handed to another method, stored in a cache, used as a map key, or returned from a getter, with zero concern about what the recipient might do to it - because nothing the recipient does can affect the object's state as seen by anyone else. A mutable object passed the same way creates a question that has to be answered every time: does the recipient own this, or are we sharing it, and if we're sharing it, who's allowed to change it?

There is also a failure-atomicity benefit that is easy to miss. If an immutable class validates its invariants in the constructor and throws on invalid input, then every Coupon object that exists is, by construction, valid - there is no Coupon floating around in a temporarily-invalid state, because there is no "later" in which its state could have drifted from valid to invalid in the first place. During code reviews, a value type passed between layers - a DTO, a calculation result, a configuration snapshot - that has no real reason to change after creation is a common candidate for this treatment: making it immutable documents "nothing downstream should be mutating this" as a compiler-enforced fact, not a comment.

How It Works

The Core Rules in Code

A traditional (non-record) immutable class with only primitive and already-immutable fields needs nothing beyond rules 1 through 3 - no defensive copies are needed because nothing about String or LocalDate can be mutated in the first place.

Java

Try it out

// File: ImmutableCouponDemo.java

import java.time.LocalDate;
import java.util.Objects;

public class ImmutableCouponDemo {

    // final - rule 3: Coupon cannot be subclassed
    static final class Coupon {

        // private final - rule 2: set once, in the constructor
        private final String code;
        private final double discountPercent;
        private final LocalDate expiryDate; // LocalDate is itself immutable

        Coupon(String code, double discountPercent, LocalDate expiryDate) {
            if (discountPercent < 0 || discountPercent > 100) {
                throw new IllegalArgumentException("discountPercent must be 0-100: " + discountPercent);
            }
            this.code = code;
            this.discountPercent = discountPercent;
            this.expiryDate = expiryDate; // no defensive copy needed - LocalDate cannot mutate
        }

        // rule 1: accessors only - no setCode(), setDiscountPercent(), etc.
        String getCode() { return code; }
        double getDiscountPercent() { return discountPercent; }
        LocalDate getExpiryDate() { return expiryDate; }

        boolean isExpired(LocalDate today) {
            return today.isAfter(expiryDate);
        }

        @Override
        public boolean equals(Object obj) {
            if (this == obj) return true;
            if (!(obj instanceof Coupon other)) return false;
            return Double.compare(discountPercent, other.discountPercent) == 0
                && code.equals(other.code)
                && expiryDate.equals(other.expiryDate);
        }

        @Override
        public int hashCode() {
            return Objects.hash(code, discountPercent, expiryDate);
        }

        @Override
        public String toString() {
            return "Coupon[code=" + code + ", discountPercent=" + discountPercent + ", expiryDate=" + expiryDate + "]";
        }
    }

    public static void main(String[] args) {
        Coupon festiveOffer = new Coupon("DIWALI25", 25.0, LocalDate.of(2026, 11, 15));

        System.out.println(festiveOffer);
        System.out.println("Expired on 2026-12-01? " + festiveOffer.isExpired(LocalDate.of(2026, 12, 1)));
        System.out.println("Expired on 2026-10-01? " + festiveOffer.isExpired(LocalDate.of(2026, 10, 1)));

        System.out.println();

        System.out.println("=== Validation runs in the constructor - invalid state is impossible ===");
        try {
            new Coupon("BAD100", 150.0, LocalDate.of(2026, 12, 31));
        } catch (IllegalArgumentException e) {
            System.out.println("Caught: " + e.getMessage());
        }
    }
}

Output:
Coupon[code=DIWALI25, discountPercent=25.0, expiryDate=2026-11-15]
Expired on 2026-12-01? true
Expired on 2026-10-01? false

=== Validation runs in the constructor - invalid state is impossible ===
Caught: discountPercent must be 0-100: 150.0

Defensive Copies - Why Both Directions Matter

The moment a field's type is mutable - any collection, java.util.Date, an array - rules 1 through 3 alone are not enough. The class below, BrokenSchedule, follows all three: no setters, private final fields, declared final. It is still not immutable, because its stops field is a reference to whatever List the caller passed in - and that list can be mutated from outside, both before and after the "immutable" object exists.

Java

Try it out

// File: DefensiveCopyDemo.java

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

public class DefensiveCopyDemo {

    // Looks immutable - final fields, no setters, final class.
    // Is NOT immutable - 'stops' is the CALLER'S list, shared directly.
    static final class BrokenSchedule {
        private final String routeName;
        private final List<String> stops;

        BrokenSchedule(String routeName, List<String> stops) {
            this.routeName = routeName;
            this.stops = stops; // stores the caller's list directly
        }

        List<String> getStops() {
            return stops; // returns the SAME list reference
        }

        @Override
        public String toString() {
            return "BrokenSchedule[" + routeName + ", stops=" + stops + "]";
        }
    }

    // Genuinely immutable - defensive copy on input AND output
    static final class SafeSchedule {
        private final String routeName;
        private final List<String> stops;

        SafeSchedule(String routeName, List<String> stops) {
            this.routeName = routeName;
            // DEFENSIVE COPY ON INPUT - a new ArrayList, independent of
            // whatever list the caller passed in, wrapped unmodifiable
            this.stops = Collections.unmodifiableList(new ArrayList<>(stops));
        }

        List<String> getStops() {
            return stops; // already a copy AND unmodifiable - safe to return
        }

        @Override
        public String toString() {
            return "SafeSchedule[" + routeName + ", stops=" + stops + "]";
        }
    }

    public static void main(String[] args) {
        List<String> originalStops = new ArrayList<>(List.of("Indiranagar", "MG Road", "Majestic"));

        System.out.println("=== BrokenSchedule - mutation AFTER construction leaks in ===");
        BrokenSchedule broken = new BrokenSchedule("Route 500", originalStops);
        System.out.println("Before mutation: " + broken);

        originalStops.add("Whitefield"); // caller mutates THEIR OWN list
        System.out.println("After mutation : " + broken);
        System.out.println("'Immutable' object changed - because it shared the caller's list");

        System.out.println();

        System.out.println("=== SafeSchedule - mutation AFTER construction has no effect ===");
        List<String> moreOriginalStops = new ArrayList<>(List.of("Indiranagar", "MG Road", "Majestic"));
        SafeSchedule safe = new SafeSchedule("Route 500", moreOriginalStops);
        System.out.println("Before mutation: " + safe);

        moreOriginalStops.add("Whitefield");
        System.out.println("After mutation : " + safe);
        System.out.println("Object unchanged - the constructor copied the list");

        System.out.println();

        System.out.println("=== getStops() on SafeSchedule also resists mutation ===");
        try {
            safe.getStops().add("Electronic City");
        } catch (UnsupportedOperationException e) {
            System.out.println("Caught: " + e.getClass().getSimpleName() + " - getStops() returned an unmodifiable view");
        }
    }
}

Output:
=== BrokenSchedule - mutation AFTER construction leaks in ===
Before mutation: BrokenSchedule[Route 500, stops=[Indiranagar, MG Road, Majestic]]
After mutation : BrokenSchedule[Route 500, stops=[Indiranagar, MG Road, Majestic, Whitefield]]
'Immutable' object changed - because it shared the caller's list

=== SafeSchedule - mutation AFTER construction has no effect ===
Before mutation: SafeSchedule[Route 500, stops=[Indiranagar, MG Road, Majestic]]
After mutation : SafeSchedule[Route 500, stops=[Indiranagar, MG Road, Majestic]]
Object unchanged - the constructor copied the list

=== getStops() on SafeSchedule also resists mutation ===
Caught: UnsupportedOperationException - getStops() returned an unmodifiable view

BrokenSchedule and SafeSchedule have identical fields, identical constructors apart from one line, and identical-looking getters. The entire difference - whether the class is actually immutable - comes down to that one line: this.stops = stops; versus this.stops = Collections.unmodifiableList(new ArrayList<>(stops));.

with Methods - Returning New Instances Instead of Mutating

Once a class is immutable, any "change" has to produce a new object. The conventional name for a method that does this is withX - it copies every field except the one being changed, and constructs a new instance.

Java

Try it out

// File: WithMethodsDemo.java

public class WithMethodsDemo {

    static final class DiscountTier {
        private final String tierName;
        private final double discountPercent;
        private final double minimumOrderValue;

        DiscountTier(String tierName, double discountPercent, double minimumOrderValue) {
            this.tierName = tierName;
            this.discountPercent = discountPercent;
            this.minimumOrderValue = minimumOrderValue;
        }

        // Each "with" method returns a NEW DiscountTier with ONE field
        // changed - 'this' is never modified
        DiscountTier withDiscountPercent(double newDiscountPercent) {
            return new DiscountTier(tierName, newDiscountPercent, minimumOrderValue);
        }

        DiscountTier withMinimumOrderValue(double newMinimumOrderValue) {
            return new DiscountTier(tierName, discountPercent, newMinimumOrderValue);
        }

        @Override
        public String toString() {
            return "DiscountTier[" + tierName + ", " + discountPercent + "%, min=Rs." + minimumOrderValue + "]";
        }
    }

    public static void main(String[] args) {
        DiscountTier original = new DiscountTier("SILVER", 5.0, 500.0);
        System.out.println("original  : " + original);

        DiscountTier promo = original.withDiscountPercent(10.0).withMinimumOrderValue(750.0);
        System.out.println("promo     : " + promo);

        System.out.println();
        System.out.println("=== 'original' is completely unchanged ===");
        System.out.println("original  : " + original);
    }
}

Output:
original  : DiscountTier[SILVER, 5.0%, min=Rs.500.0]
promo     : DiscountTier[SILVER, 10.0%, min=Rs.750.0]

=== 'original' is completely unchanged ===
original  : DiscountTier[SILVER, 5.0%, min=Rs.500.0]

original.withDiscountPercent(10.0).withMinimumOrderValue(750.0) chains two "with" calls - the first produces a new DiscountTier with the updated discount, and the second produces yet another new DiscountTier from that one, with the updated minimum order value. original itself is referenced by neither of these new objects' construction in any way that could affect it - it remains exactly as it was.

Why Immutability Enables Caching, Hashing, and Safe Sharing

Several behaviors elsewhere in the JDK exist specifically because certain types are immutable - they would be incorrect, not just unoptimized, if those types could change after construction.

WHY String CACHES ITS hashCode():
  String computes its hashCode() lazily, on the FIRST call, and stores
  it in a private field for every later call. This caching is ONLY
  correct because String is immutable - if a String's characters could
  change, a cached hashCode would go stale the instant they did, and
  every HashMap or HashSet using that String as a key would then be
  looking in the wrong bucket for it.

WHY A MUTABLE HASHMAP KEY IS DANGEROUS:
  Map<List<String>, String> cache = new HashMap<>();
  List<String> key = new ArrayList<>(List.of("a", "b"));
  cache.put(key, "value");

  key.add("c");                  // mutates the key AFTER insertion

  cache.get(key);                 // returns null
  cache.containsKey(key);         // false
  // hashCode(key) has CHANGED since insertion, so HashMap looks in a
  // DIFFERENT bucket than the one "value" was actually stored in.
  // "value" is still in the map - permanently unreachable through
  // this key.

  An immutable key type makes this entire category of bug structurally
  impossible - hashCode() cannot change after insertion if nothing
  about the object can change at all.

THREAD SAFETY WITHOUT SYNCHRONIZATION:
  Once an immutable object is fully constructed and a reference to it
  is visible to another thread, every field that thread reads reflects
  the value set during construction - there is no "in-progress
  mutation" to observe, because no mutation ever happens after
  construction. This is why immutable objects are the simplest category
  of thread-safe object: there is no shared mutable state to protect,
  so there is no synchronized block to get right.

STRING POOLING:
  String literals are stored in a shared pool - two separate "INR"
  literals in source code can refer to the SAME underlying String
  object, because String guarantees that object's content can never
  change. Sharing a MUTABLE object this way - across unrelated code,
  with no copying - would mean one piece of code could silently change
  data that every other piece of code holding the same reference
  depends on.

Real-World Example - Groww Portfolio Snapshot

An investment app needs to record a user's mutual fund holdings at a point in time - for history charts, audit trails, and "your portfolio one year ago" comparisons - without that historical record ever being at risk of being altered by later code that touches the user's current holdings. A PortfolioSnapshot that is genuinely immutable, with defensive copies on both sides of its holdings map, makes "altered by later code" structurally impossible.

Java

Try it out

// File: PortfolioSnapshot.java

import java.time.Instant;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;

public final class PortfolioSnapshot {

    private final String userId;
    private final Instant capturedAt;
    private final Map<String, Integer> holdings; // fund name -> units held

    public PortfolioSnapshot(String userId, Instant capturedAt, Map<String, Integer> holdings) {
        this.userId = userId;
        this.capturedAt = capturedAt;
        // Defensive copy on input, wrapped unmodifiable - this snapshot's
        // state is independent of whatever map the caller passed in, and
        // cannot be mutated through this field either
        this.holdings = Collections.unmodifiableMap(new HashMap<>(holdings));
    }

    public String getUserId() { return userId; }
    public Instant getCapturedAt() { return capturedAt; }

    public Map<String, Integer> getHoldings() {
        return holdings; // already a copy AND unmodifiable
    }

    public int totalUnits() {
        return holdings.values().stream().mapToInt(Integer::intValue).sum();
    }

    // "with" method - a NEW snapshot reflecting one updated holding,
    // leaving THIS snapshot completely unchanged
    public PortfolioSnapshot withUpdatedHolding(String fundName, int units, Instant capturedAt) {
        Map<String, Integer> updated = new HashMap<>(this.holdings);
        updated.put(fundName, units);
        return new PortfolioSnapshot(this.userId, capturedAt, updated);
    }

    @Override
    public String toString() {
        return "PortfolioSnapshot[userId=" + userId + ", capturedAt=" + capturedAt + ", totalUnits=" + totalUnits() + "]";
    }
}

Java

Try it out

// File: PortfolioHistoryService.java

import java.time.Instant;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class PortfolioHistoryService {

    private final List<PortfolioSnapshot> history = new ArrayList<>();

    public void capture(PortfolioSnapshot snapshot) {
        history.add(snapshot);
    }

    public static void main(String[] args) {
        PortfolioHistoryService service = new PortfolioHistoryService();

        Map<String, Integer> initialHoldings = new HashMap<>();
        initialHoldings.put("Nifty50 Index Fund", 120);
        initialHoldings.put("Gold ETF", 30);

        PortfolioSnapshot januarySnapshot = new PortfolioSnapshot(
            "USER-7842", Instant.parse("2026-01-01T00:00:00Z"), initialHoldings);
        service.capture(januarySnapshot);

        System.out.println("=== January snapshot ===");
        System.out.println(januarySnapshot);
        System.out.println("Gold ETF units: " + januarySnapshot.getHoldings().get("Gold ETF"));

        System.out.println();

        System.out.println("=== Mutating the ORIGINAL map after construction has no effect ===");
        initialHoldings.put("Gold ETF", 999);
        initialHoldings.put("New Fund", 50);
        System.out.println(januarySnapshot);
        System.out.println("Gold ETF units: " + januarySnapshot.getHoldings().get("Gold ETF"));
        System.out.println("New Fund present? " + januarySnapshot.getHoldings().containsKey("New Fund"));

        System.out.println();

        System.out.println("=== getHoldings() returns an unmodifiable view ===");
        try {
            januarySnapshot.getHoldings().put("Hacked Fund", 1);
        } catch (UnsupportedOperationException e) {
            System.out.println("Caught: " + e.getClass().getSimpleName());
        }

        System.out.println();

        System.out.println("=== withUpdatedHolding() produces a NEW snapshot ===");
        PortfolioSnapshot februarySnapshot = januarySnapshot.withUpdatedHolding(
            "Gold ETF", 45, Instant.parse("2026-02-01T00:00:00Z"));
        service.capture(februarySnapshot);

        System.out.println("January : " + januarySnapshot);
        System.out.println("February: " + februarySnapshot);

        System.out.println();
        System.out.println("=== History now contains both snapshots, independently ===");
        System.out.println("History size: " + service.history.size());
    }
}

Output:
=== January snapshot ===
PortfolioSnapshot[userId=USER-7842, capturedAt=2026-01-01T00:00:00Z, totalUnits=150]
Gold ETF units: 30

=== Mutating the ORIGINAL map after construction has no effect ===
PortfolioSnapshot[userId=USER-7842, capturedAt=2026-01-01T00:00:00Z, totalUnits=150]
Gold ETF units: 30
New Fund present? false

=== getHoldings() returns an unmodifiable view ===
Caught: UnsupportedOperationException

=== withUpdatedHolding() produces a NEW snapshot ===
January : PortfolioSnapshot[userId=USER-7842, capturedAt=2026-01-01T00:00:00Z, totalUnits=150]
February: PortfolioSnapshot[userId=USER-7842, capturedAt=2026-02-01T00:00:00Z, totalUnits=165]

=== History now contains both snapshots, independently ===
History size: 2

Every line of PortfolioSnapshot traces back to one of the five rules: no setters (rule 1), private final fields including the map reference itself (rule 2), final class (rule 3), new HashMap<>(holdings) in the constructor (rule 4), and Collections.unmodifiableMap(...) making the same copy safe to hand out from getHoldings() (rule 5). withUpdatedHolding never touches this.holdings - it builds a fresh map from a copy of it, and hands that to a brand-new PortfolioSnapshot.

Immutable Class vs final Class vs final Fields

	What It Means	What It Prevents	What It Does NOT Prevent
`final` field	The field cannot be reassigned after construction	`this.list = anotherList` later in any method	`this.list.add(...)` - the OBJECT the field refers to can still be mutated
`final` class	The class cannot be extended	A subclass adding mutable state or overriding behavior	The class's OWN methods from mutating its own fields' contents, if those fields are mutable types
Immutable class	No object of this class ever has different observable state after construction	Both of the above, AND mutation of anything reachable from any field, from anywhere, ever	-

The middle row is where the most common misconception lives: a class with every field final and the class itself final LOOKS like it satisfies every requirement - and for fields of immutable types, it does. The moment one field is a List, a Date, or an array, final on that field guarantees only that the reference never changes; the object on the other end of that reference is a completely separate question, answered by rules 4 and 5, not by final at all.

Best Practices

Prefer fields of types that are already immutable. String, the boxed primitive wrapper types, LocalDate/LocalDateTime/Instant, BigDecimal, and records (Java 16+) all need no defensive copying when used as fields - rules 4 and 5 simply do not apply to them. A class built entirely from such types satisfies all five rules the moment rules 1 through 3 are satisfied.

Remember that records automate rules 1 through 3, but not 4 and 5. A record gives every component a private final field, no setters, and an implicitly final class - for free. If a record component's type is mutable - a List, an array, a Date - the record's canonical constructor still stores whatever reference it is given, and the generated accessor still returns that same reference, exactly like BrokenSchedule above. A record with a mutable component type needs a compact constructor performing the same defensive copy this article describes - records narrow the gap, they do not remove it.

Validate every invariant in the constructor, and nowhere else. Because an immutable object's state can never be corrected after construction, a constructor that lets invalid data through creates an object that is permanently invalid - there is no setter to call later to fix it. Coupon's discount-percentage check above is the entire validation surface for that class; if it passes, every Coupon that will ever exist with that data is valid, for its whole lifetime.

Provide withX methods for the changes callers actually need, rather than forcing manual reconstruction. A caller that needs "the same DiscountTier, but with a different minimum order value" should not need to read all of DiscountTier's fields and call its full constructor - withMinimumOrderValue(750.0) says what changed, and nothing else, while the class's invariants (whatever they are) still get re-checked by the constructor it delegates to.

Common Mistakes

Mistake 1 - A final Field Referencing a Mutable Object

Java

Try it out

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

// WRONG - 'items' is final, so it can never be REASSIGNED. But it is
// an ArrayList - its CONTENTS can still change, through this class's
// own methods or through anyone holding the same reference.
final class WishlistBroken {
    private final List<String> items;

    WishlistBroken(List<String> items) {
        this.items = items; // no copy
    }

    void addItem(String item) {
        items.add(item); // mutates the 'final' field's referent directly
    }

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

// CORRECT - if the class needs to support adding items, that itself
// is a sign it should NOT be immutable - OR, if it should be
// immutable, "adding an item" becomes a "with" method returning a
// NEW Wishlist with a NEW, larger list
final class WishlistFixed {
    private final List<String> items;

    WishlistFixed(List<String> items) {
        this.items = java.util.Collections.unmodifiableList(new ArrayList<>(items));
    }

    WishlistFixed withItem(String item) {
        List<String> updated = new ArrayList<>(items);
        updated.add(item);
        return new WishlistFixed(updated);
    }

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

Mistake 2 - A Getter Returning the Internal Mutable Field Directly

Java

Try it out

import java.util.HashMap;
import java.util.Map;

// WRONG - the constructor copies 'attributes' correctly, but
// getAttributes() then hands out the INTERNAL map directly. A caller
// of getAttributes() can mutate it, and that mutation affects THIS
// object's internal state from then on.
final class ProductBroken {
    private final Map<String, String> attributes;

    ProductBroken(Map<String, String> attributes) {
        this.attributes = new HashMap<>(attributes); // copy on input - good
    }

    Map<String, String> getAttributes() {
        return attributes; // MUTABLE map, returned directly - bad
    }
}

// CORRECT - wrap the internal copy as unmodifiable (or return a
// further copy) from the getter as well
final class ProductFixed {
    private final Map<String, String> attributes;

    ProductFixed(Map<String, String> attributes) {
        this.attributes = java.util.Collections.unmodifiableMap(new HashMap<>(attributes));
    }

    Map<String, String> getAttributes() {
        return attributes; // already unmodifiable - safe
    }
}

Mistake 3 - Storing a java.util.Date Field Without Defensive Copies

Java

Try it out

import java.util.Date;

// WRONG - java.util.Date is MUTABLE: it has setTime(), and several
// deprecated but still-present setters. Storing one directly, and
// returning it directly, both leak a reference to a mutable object -
// exactly the same problem as a List or Map field, just less obvious
// because Date "looks like" a simple value.
final class EventBroken {
    private final String name;
    private final Date scheduledAt;

    EventBroken(String name, Date scheduledAt) {
        this.name = name;
        this.scheduledAt = scheduledAt; // no copy
    }

    Date getScheduledAt() {
        return scheduledAt; // returns the mutable Date directly
    }
}

// CORRECT - copy on input AND output, using Date's millisecond value
final class EventFixed {
    private final String name;
    private final Date scheduledAt;

    EventFixed(String name, Date scheduledAt) {
        this.name = name;
        this.scheduledAt = new Date(scheduledAt.getTime()); // copy on input
    }

    Date getScheduledAt() {
        return new Date(scheduledAt.getTime()); // copy on output
    }
}

// BEST - avoid java.util.Date entirely. java.time.Instant,
// java.time.LocalDate, and java.time.LocalDateTime are all immutable,
// so neither copy above is needed in the first place
final class EventBest {
    private final String name;
    private final java.time.Instant scheduledAt;

    EventBest(String name, java.time.Instant scheduledAt) {
        this.name = name;
        this.scheduledAt = scheduledAt; // Instant is immutable - safe as-is
    }

    java.time.Instant getScheduledAt() { return scheduledAt; }
}

Mistake 4 - Assuming a Record With a Mutable Component Is Fully Immutable

Java

Try it out

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

// WRONG - 'tags' is a List, a mutable type. The record gives 'tags' a
// private final FIELD - the reference cannot be reassigned - but the
// canonical constructor stores whatever List reference it is given,
// and the generated accessor tags() returns that same reference.
record ProductBroken(String name, List<String> tags) {}

List<String> mutableTags = new ArrayList<>(List.of("sale", "trending"));
ProductBroken product = new ProductBroken("Shoes", mutableTags);

mutableTags.add("clearance");          // mutates the SHARED list
product.tags().add("flash-sale");       // mutates it AGAIN, via the accessor
// product.tags() now reflects BOTH external mutations

// CORRECT - a compact constructor performing the SAME defensive copy
// this article has used throughout, plus an overridden accessor
record ProductFixed(String name, List<String> tags) {
    ProductFixed {
        tags = List.copyOf(tags); // defensive copy on input, unmodifiable
    }
    // List.copyOf() already returns an unmodifiable list, so the
    // generated accessor needs no further change for output safety
}

Interview Questions

Q1. What is an immutable class, and what are the core rules for creating one?

An immutable class is one where every object has the same observable state for its entire lifetime - no field, and nothing reachable from any field, ever changes after construction. The core rules: provide no mutator methods; make every field private and final; make the class final (or otherwise prevent subclasses from breaking the guarantee); make a defensive copy of any mutable object passed into the constructor before storing it; and make a defensive copy (or return an unmodifiable view of the internal copy) of any mutable object returned from a getter. The first three rules are sufficient when every field's type is itself immutable; the last two become necessary the moment any field's type is mutable.

Q2. Why is making a field final not sufficient to make a class immutable?

final on a field guarantees only that the field cannot be reassigned after the constructor runs - this.list = anotherList later in the class would be a compile error. It says nothing about the object the field refers to. If that object is a List, an array, or a Date, its contents can still be changed - through the class's own methods calling mutators on it, or through any external code that holds a reference to the same object, whether because the constructor stored the caller's reference directly or because a getter returned the internal reference directly. final controls the field; defensive copies control the object.

Q3. What is a defensive copy, and why are two needed - one for input, one for output?

A defensive copy is a new, independent object containing the same data as a mutable object the class has been given, or is about to give out - created specifically so that no one outside the class holds a reference to the same object the class itself holds. The input copy, made in the constructor, ensures the caller's continued access to the object they passed in cannot affect this object's state afterward. The output copy, made in (or before) any getter that would otherwise return a mutable field, ensures that a caller of the getter cannot affect this object's state by mutating what they were handed. Either one alone leaves a path for external mutation; both together close it.

Q4. Why does String cache its hashCode, and why would this be unsafe for a mutable class?

String.hashCode() computes the hash once, on first use, and stores it in a field for all subsequent calls - this is correct only because a String's characters can never change, so the cached value can never become wrong. A mutable class caching its hashCode() the same way would produce a stale value the moment any field used in the hash computation changed - and that stale value could then cause HashMap and HashSet to look in the wrong bucket for an object whose hash code no longer matches where it was originally stored, effectively losing the object inside the collection without it being removed.

Q5. How do records relate to immutability - do they provide it automatically?

Records automate the first three rules of immutability: every component becomes a private final field, no setters are generated, and every record is implicitly final. For components of already-immutable types, this is the entire job - the record is fully immutable with zero extra code. For components of mutable types - List, Map, arrays, Date - records do NOT automatically apply rules 4 and 5; the canonical constructor stores whatever reference it receives, and the generated accessor returns that same reference, exactly as a hand-written class without defensive copies would. A compact constructor performing the same copy described in this article - often using List.copyOf() or similar - is still required for genuine immutability in that case.

Q6. Why are immutable objects considered thread-safe without synchronization?

Thread-safety problems arise from multiple threads observing or modifying shared mutable state at the same time - one thread reading a value while another is in the middle of changing it, or two threads changing it simultaneously with one update lost. An immutable object has no state that ever changes after construction, so there is no "in the middle of changing it" for any thread to observe, and no concurrent modification possible at all - any number of threads reading the same immutable object at the same time simply read the same, unchanging values. This eliminates the entire category of bug that synchronized, locks, and volatile exist to prevent, for that object - not by handling the race correctly, but by ensuring there is no race to handle.

FAQs

Is making a class final required for immutability?

final on the class is the standard way to satisfy rule 3 - preventing a subclass from adding mutable state or overriding a method in a way that breaks the guarantee. It is not the ONLY way: a class with all-private constructors (so it can only be instantiated through static factory methods, and never subclassed outside the file) achieves the same goal without the final keyword itself. In practice, final is by far the simplest and most common approach, and records satisfy this rule automatically by being implicitly final.

Can an immutable class have mutable fields if they're never exposed?

If a field's type is mutable but the field is never read from outside the constructor (used only internally, during construction, to compute other final fields, and then discarded), it does not threaten immutability - because nothing about the object's observable state depends on it after construction. However, if the mutable object is STORED as a field and reachable later - even if no getter directly returns it, but it is used by other methods that could expose its state indirectly - the same defensive-copy reasoning applies. The safest framing: any field whose type is mutable needs rules 4 and 5 considered, regardless of whether a getter for it exists.

Why is java.util.Date often cited as a mistake in immutable class design?

Because Date looks like a simple value - "a point in time" - but has mutator methods (setTime(), and older deprecated setters for year, month, and so on) that most developers do not expect a "value type" to have. A field of type Date, stored and returned without defensive copies, is exactly as exposed to external mutation as a field of type List - the mistake is identical, but Date disguises it better, which is why this specific case shows up so often in both real bugs and interview questions. java.time.Instant, LocalDate, and LocalDateTime are immutable replacements that avoid the issue entirely.

Do immutable objects use more memory because of with methods creating new instances?

Each withX call does allocate a new object, where a mutable design would modify one object in place - so yes, there is more allocation. In practice, for the kinds of objects immutability is recommended for (configuration snapshots, value types, DTOs passed between layers), these objects tend to be small and short-lived, and the JVM's generational garbage collector is specifically optimized for large numbers of small, short-lived objects. The cost is real but is rarely the bottleneck it might seem; the debugging time saved by eliminating "who mutated this and when" questions is the trade typically being made.

Can an immutable class be serialized safely?

Yes, and immutable classes are generally easier to serialize correctly than mutable ones - there is no risk of serializing an object mid-mutation, and deserialization producing a fully-formed, valid object in one step matches how immutable objects are meant to be constructed. One detail worth checking for hand-written immutable classes (as opposed to records, which the JDK has updated serialization support for) is that the deserialization process bypasses the normal constructor by default - if the constructor performs validation or defensive copying that matters for correctness, a readObject method may be needed to re-apply it during deserialization too.

How do immutable objects work with equals() and hashCode() in collections like HashSet?

Immutable objects are close to ideal HashSet elements and HashMap keys specifically because their hashCode() cannot change after insertion - the object will always be found in the bucket corresponding to the hash code it had when it was added, because that hash code can never become outdated. Coupon's equals() and hashCode() in the example above are based on code, discountPercent, and expiryDate - none of which can change after construction, so two Coupon objects that are equal() today will remain equal() (and hash identically) for as long as both objects exist, which is exactly the contract HashSet and HashMap rely on.

Summary

An immutable class guarantees that every object of that class has the same state for its entire lifetime - and that guarantee is built from five rules working together, not any one of them alone. No setters and final fields handle the easy case - fields of types that cannot themselves be mutated. The moment a field's type IS mutable - a List, a Map, an array, or java.util.Date - defensive copies on both input and output are what close the remaining gap, and skipping either one leaves a class that looks immutable while still being fully mutable through a side door.

Records automate the easy case completely and remove most of the boilerplate from the hard case, but do not remove the defensive-copying decision itself - a record with a List component still needs a compact constructor copying it, for exactly the reason a hand-written class would.

The question worth asking about any class whose objects are meant to represent a fixed value: for every field, is its type something that can be mutated after construction - and if so, does this class's constructor and getters ever hand out a reference to that exact object, to or from the outside? If the answer to the second question is ever yes, the class is not immutable yet, regardless of how many final keywords it has.

What to Read Next

Continue Learning Advanced OOP

Next Step

Object Cloning

Learn how to create a copy of an existing object.

→

Overloading vs Overriding

See how overloading and overriding are actually different.

→

Custom Annotations

Learn how to create your own annotation.

→

Anonymous Classes

Learn how to create a one-off class without naming it.

→

←

PreviousSealed Classes (Java 17+)

NextObject Cloning

→