Why must local variables captured by a Java lambda be effectively final?

Explains Java lambda capture through copied local values, mutable referenced objects, lifetime, and safe state handling.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

A lambda can capture a local variable only if it is final or effectively final, meaning the variable is assigned once and never reassigned. The lambda captures the local value, and it may run after the method's stack frame has returned, so Java avoids mutable shared local-variable slots with unclear lifetime and visibility. A captured object reference may still point to a mutable object. The restriction prevents reassigning the local variable, not mutating that object.

Full answer below

Practice focus

Effectively final locals, capture semantics, shared mutable objects, and avoidance of unsafe stateful lambdas.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
The restriction applies to reassigning the local variable, not to every object reachable through its captured reference.
A lambda can capture a local variable only if it is final or effectively final, meaning the variable is assigned once and never reassigned. The lambda captures the local value, and it may run after the method's stack frame has returned, so Java avoids mutable shared local-variable slots with unclear lifetime and visibility. A captured object reference may still point to a mutable object. The restriction prevents reassigning the local variable, not mutating that object.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Capturing int limit = 10 is fine if limit is never reassigned. Capturing a and calling can compile because the list reference is stable, but it introduces side effects and may be unsafe if the lambda runs concurrently. Using a one-element array or atomic type only to bypass the rule usually hides poor ownership. A reduction, returned result, or explicitly owned state is often clearer.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Believing effectively final makes the referenced object immutable.
Using a mutable holder only to bypass the compiler rule.
Sharing a captured collection across parallel work.
Confusing captured local values with instance fields.

Why must local variables captured by a Java lambda be effectively final?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue practice

Skill areas

Suggest an improvement

Found this answer useful?