Why does declaring a variable inside versus outside a loop body matter, especially for lambdas/closures that capture it?

## Per-entry instantiation A core rule of block scope: **every time control enters a block, a fresh set of that block's local variables is created**, and they are discarded when the block exits. A loop body is a block, so its locals are recreated on each iteration. ```java for (int i = 0; i < 3; i++) { int squared = i * i; // a NEW 'squared' each iteration } ``` Contrast a variable declared **outside** the loop, which is one variable reused (mutated) across all iterations: ```java int sum = 0; // one variable for (int i = 0; i < 3; i++) { sum += i; // same 'sum' mutated each time } ``` ## What 'effectively final' means A local variable (or parameter) is **effectively final** if it is assigned exactly once and never reassigned afterward — i.e. you *could* add the `final` keyword without a compile error. Java introduced this concept so lambdas and anonymous classes don't require you to literally write `final` everywhere. ## Why closures can only capture effectively-final locals A **closure** (a lambda or anonymous inner class) can refer to local variables of the enclosing method/block — this is **capture**. Java captures by **value**: it copies the variable's value into the closure at the moment the closure is created. If the original could keep changing, the copy and the original would diverge confusingly, so Java requires captured locals to be effectively final. (Fields don't have this restriction because they are captured via the enclosing object reference, not by value.) ## The loop-capture bug and how scope fixes it Because a loop body's local is a fresh instance per iteration, it is effectively final *within that iteration* and can be captured cleanly: ```java List<Runnable> tasks = new ArrayList<>(); for (int i = 0; i < 3; i++) { int captured = i; // fresh per iteration -> effectively final tasks.add(() -> System.out.println(captured)); } // prints 0, 1, 2 — each lambda has its own 'captured' ``` But you **cannot** capture the loop index `i` of a classic `for` directly: ```java for (int i = 0; i < 3; i++) { tasks.add(() -> System.out.println(i)); // COMPILE ERROR: i is not effectively final } ``` `i` is reassigned every iteration (`i++`), so it is not effectively final. The fix is exactly the per-iteration copy above. (In languages without per-iteration freshness, such as older JavaScript with `var`, all the closures would have shared one `i` and printed `3, 3, 3` — Java's scope rules plus the effectively-final requirement prevent that footgun.) ## The enhanced for-loop is friendly here The enhanced for-loop variable is conceptually a fresh local each iteration, so it can be captured directly: ```java for (String name : names) { tasks.add(() -> System.out.println(name)); // fine: 'name' is effectively final per iteration } ``` ## Practical guidance - Declare variables in the **narrowest** block that needs them. - If a lambda inside a loop must capture an index, copy it into a per-iteration local first. - Prefer enhanced for / streams where possible; their loop variables capture cleanly. - Remember: scope governs visibility; the per-entry-instantiation rule governs which *instance* you get and therefore what a closure captures.