Why Must Lambda Variables Be Effectively Final?

Effectively final means a variable is never reassigned after its initialisation. You do not have to declare it final — the compiler just checks that no assignment to it appears anywhere after the declaration.

The rule exists because a lambda does not run immediately. The lambda body may execute long after the enclosing method has returned, possibly on another thread, and by then the enclosing frame is gone. If the lambda could see a variable that had been reassigned, it would have no way to know which value it was supposed to use, and the result would depend on timing. The rule removes the ambiguity by guaranteeing that a captured variable always has the value it had when the lambda was created.

import java.util.function.Supplier;

public class Main {
    public static void main(String[] args) {
        int base = 10;
        Supplier<Integer> supplier = () -> base + 5;   // base is effectively final
        System.out.println("supplier : " + supplier.get());

        // Uncommenting the line below makes the lambda fail to compile:
        // base = 20;
        // The error says the local variable base must be final or effectively final.
    }
}

The output shows the working case. The lambda captures the int base, and because base is never reassigned the compiler is happy.

Notice what the rule does not say. It does not require the captured object to be immutable. If you capture a StringBuilder and mutate it inside the lambda, that is perfectly legal, because the rule is about reassigning the variable, not about changing the object. The same applies to a field — fields are not subject to the rule at all, since a lambda can read and write this.field freely.

The reason the rule covers only local variables and parameters is that those are the ones that live on the stack frame of the enclosing method. When the method returns, the frame is gone, and the only way for the lambda to keep using them is for the compiler to copy them into the lambda's own storage. That copy is only meaningful if the value does not change.

There are three workarounds, and they are not equally good.

The first is to refactor the code so the variable never needs to change. Often the variable was a counter or an accumulator that the lambda does not need to own — moving the loop outside the lambda, or using a stream operation, removes the problem entirely.

The second is to use a mutable holder: an array, a List or an AtomicInteger that you capture instead of the value. The reference to the holder is effectively final, so the compiler is satisfied, while the object it points at can change. This is a legitimate technique when the state genuinely has to be shared with the lambda.

The third is to make the variable a field of the enclosing class, since fields are not subject to the effectively final rule.

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Supplier;

public class Main {
    public static void main(String[] args) {
        // Workaround 1: a mutable holder.
        int[] box = {10};
        Supplier<Integer> viaArray = () -> box[0] + 5;
        System.out.println("holder   : " + viaArray.get());

        // Workaround 2: an AtomicInteger for genuinely changing state.
        AtomicInteger counter = new AtomicInteger(10);
        Supplier<Integer> viaAtomic = () -> counter.get() + 5;
        System.out.println("atomic   : " + viaAtomic.get());
        counter.set(100);
        System.out.println("after set: " + viaAtomic.get());

        // Workaround 3: keep the mutable state in a list.
        List<String> log = new ArrayList<>();
        Runnable task = () -> log.add("ran");
        task.run();
        task.run();
        System.out.println("list     : " + log);
    }
}

The output shows all three. The holder and the atomic counter both let the lambda see a value that changes after the lambda was created. The list accumulates two entries, because each call of the runnable appended to the shared list.

Which to use. For a counter touched by several threads, use an AtomicInteger or a LongAdder, because the holder approach with a plain int is not thread safe. And if the state is a collection that the lambda mutates, use a concurrent collection if the lambda might run on more than one thread.

The design point worth making in an interview is that the effectively final rule is a symptom of a deeper truth: lambdas are for stateless, side-effect-free computation. When you find yourself fighting the rule, it is often a sign the work should be expressed differently — as a stream pipeline, as a returned value, or as a separate object with its own state.