Effectively final and variable capture

For this lesson, we'll focus on local variable capture in lambdas, anonymous classes and local classes, why the rule exists, how fields and this are different, the holder workaround smell, capturing versus non-capturing lambda allocation, and loop variable capture. Interviewers ask this because the compiler error is common, but the real answer is about stack frames, copied values and mutability boundaries.

01Picture it first: a boarding pass, not a walkie-talkie

Think of a captured local as a boarding pass copied into your bag. The gate agent writes your seat on the pass, you walk away, and the pass does not stay connected to the airline desk. If the desk later changes its screen, your paper copy does not magically update.

A mutable field is different. Capturing this is like carrying a key card to the airline office. Every time you use it, you walk back to the office and read the current screen.

Fig. 1

A lambda copies an effectively final local value into its own object while a lambda that reads an instance field captures this and reads the field through the object each time

Notice the important line in the picture: locals are copied by value of the variable, while fields are reached through an object reference. If the local is a reference, the reference value is copied, not the whole object. The object can still be mutable.

02Variable capture under the hood

import java.util.List;
import java.util.function.Predicate;

record Order(String id, int cents) { }

public class CaptureDemo {
    public static void main(String[] args) {
        int minCents = 1_000;
        Predicate<Order> expensive = order -> order.cents() >= minCents;

        List<Order> orders = List.of(new Order("o-1", 900), new Order("o-2", 1_400));
        System.out.println(orders.stream().filter(expensive).count()); // 1

        // minCents = 2_000; // uncommenting this makes the lambda line fail
    }
}

The commented reassignment is enough to break effective finality. It does not matter that the reassignment appears after the lambda. The compiler analyzes the whole local variable and refuses the capture if the variable is assigned again.

Notice three things:

• The word final is optional. final int minCents = 1_000; and int minCents = 1_000; behave the same here if there is no reassignment.
• The rule covers locals and parameters. A method parameter used in a lambda must also be final or effectively final.
• Mutating the object is not reassignment. If minCents were a List<Integer> thresholds, calling thresholds.add(1_000) would not change whether the local reference is effectively final.

The JLS wording lives in two places. JLS 4.12.4 defines effectively final variables. JLS 15.27.2 says a local variable, formal parameter or exception parameter used but not declared in a lambda body must be final or effectively final.

Under the covers, the lambda does not keep a pointer to your method's local variable slot. A method's local variables live in that method's stack frame. Once the method returns, that frame is gone. A lambda can escape the method and run later, so Java captures the value it needs.

import java.util.function.Supplier;

public class EscapeDemo {
    static Supplier<String> receiptPrinter(String orderId) {
        String prefix = "paid:";
        return () -> prefix + orderId;
    }

    public static void main(String[] args) {
        Supplier<String> printer = receiptPrinter("o-42");
        System.out.println(printer.get()); // paid:o-42
    }
}

By the time printer.get() runs, receiptPrinter has already returned. The local variables prefix and orderId are gone from the stack, but their values were copied into the lambda instance. That is why the program still works.

If Java allowed prefix = "refunded:" after the lambda was created, we would need to answer an awkward question: should printer.get() read the old copy or the new local? Java avoids that split-brain model by allowing only locals that cannot be reassigned.

03Fields and this are captured differently

import java.util.function.LongUnaryOperator;

public class PricingRules {
    private int discountPct = 10;

    LongUnaryOperator currentDiscount() {
        return cents -> cents * (100 - discountPct) / 100;
    }

    public static void main(String[] args) {
        PricingRules rules = new PricingRules();
        LongUnaryOperator price = rules.currentDiscount();

        System.out.println(price.applyAsLong(1_000)); // 900
        rules.discountPct = 25;
        System.out.println(price.applyAsLong(1_000)); // 750
    }
}

The lambda reads the updated field. It captured this, and every call follows that reference to the current discountPct. There is no effectively-final rule for fields because fields do not live in a disappearing stack frame.

This is also where lambdas differ from anonymous classes in a way candidates often miss. Inside a lambda, this means the enclosing object. Inside an anonymous class, this means the anonymous object itself.

public class ThisDemo {
    private final String name = "screen";

    Runnable lambda() {
        return () -> System.out.println(this.name); // this is ThisDemo
    }

    Runnable anonymous() {
        return new Runnable() {
            private final String name = "callback";
            @Override public void run() {
                System.out.println(this.name);      // this is the anonymous Runnable
            }
        };
    }
}

Use that fact in interviews. If the lambda body reads an instance field or calls an instance method, it keeps the enclosing object reachable. In UI code, listener registries and long-lived executors, that can turn into a memory leak.