Lambda Capture & `this`

## Setup: what is a lambda and what is 'capture'? A **lambda expression** in Java (e.g. `() -> x + 1`) is a compact way to create an instance of a functional interface — an object with a single method. A lambda can refer to variables from the code around it; using such an outside variable inside the lambda is called **capturing** it. The lambda then 'closes over' those variables, which is why lambdas are a form of **closure**. ## The three kinds of variables a lambda might reference 1. **Local variables** (and method parameters) — declared inside the enclosing method, living on that method's **stack frame** (the per-call chunk of memory holding its locals). 2. **Instance fields** — variables belonging to the surrounding object, reached via `this.field`. 3. **Static fields** — variables belonging to the class. The 'effectively final' rule applies **only to local variables and parameters** (category 1). Fields (categories 2 and 3) can be freely read and even mutated by a lambda. ## What 'effectively final' means A local variable is **effectively final** if it is assigned exactly once and never reassigned afterward — i.e. you *could* put the keyword `final` in front of it and the code would still compile. You don't have to write `final`; the compiler infers it. Example: ```java int a = 5; // assigned once, never changed -> effectively final, OK to capture int b = 5; b = 6; // reassigned -> NOT effectively final -> cannot capture ``` ## Why the restriction exists — capture-by-value When a lambda captures a local, Java does **not** keep a live pointer to the variable's stack slot. It **copies the value** into the lambda object at the moment the lambda is created. This is **capture by value**. Why copy instead of link? Because the lambda can outlive the method. Consider returning a lambda from a method: the method's stack frame is destroyed when it returns, taking its locals with it. If the lambda held a pointer into that dead frame, it would read garbage. Copying the value sidesteps this — the value lives inside the lambda object on the heap. But a copy creates a consistency problem: if the original local could still change after the copy was taken, the lambda's copy and the live variable would disagree, and it would be unclear which value the lambda 'should' see. Allowing mutation would also invite **data races** when the lambda runs on another thread. Java resolves all of this by simply forbidding the source from changing: the local must be effectively final, so the single copied value is unambiguously correct. (Languages like JavaScript instead capture the variable *binding* itself, so mutations are visible inside the closure. Java deliberately chose the simpler value-capture model.) ## Why fields are exempt A lambda that reads `count` where `count` is an instance field is really reading `this.count`. What gets captured is the **reference `this`** (one value, effectively final itself), and field access is performed *through* that reference at run time. So the lambda always sees the field's **current** value and may even change it — no copy of the field is made, so no consistency rule is needed. Static fields work the same way through the class. ## The classic workaround and why to avoid it If you truly need a mutable counter visible to a lambda, people sometimes wrap it: `int[] counter = {0};` then `counter[0]++` inside the lambda. The **array reference** is effectively final; only its contents change. This compiles but reintroduces exactly the race risk the rule prevents — prefer an explicit field, an `AtomicInteger`, or a redesign. ## How to derive your own answer - Junior: 'the variable can't change after it's set, or it won't compile.' - Middle: add *why* — capture is by value because the lambda may outlive the stack frame. - Senior: add the field exemption (`this` is captured, fields read live) and the thread-safety motivation. - Principal: contrast with binding-capture languages and the array/AtomicInteger trade-offs.