Nested Classes and Immutable Objects

Why this matters

• Non-static inner classes hold a hidden reference to their enclosing instance, which is a real and common cause of memory leaks.
• Immutability removes the need for synchronisation entirely, which is why it is the foundation of safe concurrent code.
• Records, covered in the Java 17 module, are the language's answer to the immutable-class boilerplate shown here — but the manual recipe is still what you need for anything with more than plain data.

Four kinds of nested class

public class Outer {
    private String secret = "outer state";

    static class StaticNested {
        void show() {
            // no access to `secret` — there is no enclosing instance
        }
    }

    class Inner {
        void show() {
            System.out.println(secret);     // reaches private outer state
        }
    }

    void method() {
        class Local {
            void show() { System.out.println(secret); }
        }
        new Local().show();

        Runnable anonymous = new Runnable() {
            @Override public void run() { System.out.println(secret); }
        };
        anonymous.run();
    }
}

Creating them differs, and the inner-class syntax surprises people:

Outer.StaticNested nested = new Outer.StaticNested();   // no outer instance needed

Outer outer = new Outer();
Outer.Inner inner = outer.new Inner();                   // requires one

Anonymous classes versus lambdas

// Anonymous class: verbose, but works for any interface or abstract class
Comparator<String> byLength = new Comparator<String>() {
    @Override
    public int compare(String a, String b) {
        return Integer.compare(a.length(), b.length());
    }
};

// Lambda: only for functional interfaces, far shorter
Comparator<String> shorter = (a, b) -> Integer.compare(a.length(), b.length());

Both capture local variables only if those variables are effectively final — assigned once and never changed. The compiler copies the value, so allowing reassignment would make the copy and the original disagree.

Immutable objects

An object is immutable when nothing can change its observable state after construction. Five steps make that true.

public final class Itinerary {
    private final String traveller;
    private final LocalDate departure;      // immutable type: safe as-is
    private final List<String> stops;       // mutable type: needs care

    public Itinerary(String traveller, LocalDate departure, List<String> stops) {
        this.traveller = Objects.requireNonNull(traveller);
        this.departure = Objects.requireNonNull(departure);
        this.stops = List.copyOf(stops);    // defensive copy, already unmodifiable
    }

    public String traveller()    { return traveller; }
    public LocalDate departure() { return departure; }
    public List<String> stops()  { return stops; }        // safe: the copy is unmodifiable

    /** Changes produce a new object rather than mutating this one. */
    public Itinerary withDeparture(LocalDate newDate) {
        return new Itinerary(traveller, newDate, stops);
    }
}

The withX method is the idiomatic way to offer "modification" on an immutable type. It returns a new instance and leaves the original untouched, exactly as String.toUpperCase() does.

What immutability buys you

The cost is allocation: every change creates an object. For small objects this is cheap, and generational garbage collection is specifically optimised for short-lived ones. Where it genuinely matters, as in string building inside a loop, use the mutable builder and produce an immutable result at the end.

Common misreadings

• "final on a field makes the object immutable." It fixes the reference, not the object. private final List<String> items can still be cleared.
• "Inner and nested classes are the same thing." "Inner" specifically means non-static, with an enclosing instance. The difference is the leak risk.
• "A lambda is just shorthand for an anonymous class." this means different things, and they compile differently. The resemblance is superficial.
• "Immutable classes cannot have collections." They can, with a defensive copy in and an unmodifiable view out.
• "Immutability is slow." Extra allocation of short-lived objects is what generational collectors handle best. Measure before assuming.