Local & Anonymous Classes

## Setup: what 'capture' means When a local class or anonymous class refers to a local variable (or method parameter) from the method it's declared in, that is called **capturing** the variable. Example: ```java Runnable makeTask(String name) { int id = 42; return new Runnable() { @Override public void run() { System.out.println(name + " " + id); // captures `name` and `id` } }; } ``` Here the returned `Runnable` may be run much later, after `makeTask` has already returned. By then the method's **stack frame** — the chunk of memory holding `id`, `name`, and other locals — has been destroyed. So the object can't point at those stack slots. ## How Java actually captures The compiler solves this by **copying the value** of each captured local into a hidden (synthetic) field of the generated inner-class instance at the moment the instance is created. The inner object then reads its own copy, which survives on the heap as long as the object does. Primitives are copied by value; object references are copied (the *reference* is copied, so both point at the same heap object). ## The rule: effectively final Because the inner object holds an independent copy, Java forbids the original local from being **reassigned** anywhere in the method. A variable that is assigned once and never reassigned is **effectively final** — it behaves as if you wrote `final`, even though you didn't. Before Java 8 you had to spell out `final`; since Java 8 the compiler infers it, and you only get a compile error if you actually do reassign. Why the restriction? If reassignment were allowed, the method's copy and the captured copy could **drift apart**, and it would be ambiguous which value the inner class 'should' see — the one at capture time or the latest one. Rather than pick a confusing semantics, Java rules it out at compile time. (Some languages like JavaScript capture the variable *binding* and let it mutate; Java deliberately chose value capture for simplicity and thread-safety.) ## What counts as a reassignment ```java int x = 1; x = 2; // reassignment -> x is NOT effectively final Runnable r = () -> System.out.println(x); // compile error ``` Mutating the *object* a final reference points to is fine — it's the *variable* that must not be reassigned: ```java List<String> list = new ArrayList<>(); // effectively final reference Runnable r = () -> list.add("ok"); // OK: we mutate the object, not the variable ``` ## Working around it when you truly need mutable captured state Three idioms: 1. **One-element array** — `int[] box = {0};` then `box[0]++` inside; the *reference* `box` stays effectively final while the contents change. 2. **Atomic types** — `AtomicInteger count = new AtomicInteger();` then `count.incrementAndGet()`; also thread-safe. 3. **A field of the enclosing object** — instance and static fields are *not* captured by value. The inner class reaches them through the captured **enclosing-instance reference** (for an instance field) or directly (for a static field), so writes are visible and allowed. ## Note on fields vs locals The effectively-final rule applies **only to local variables and parameters**, not to fields. That's because a field lives on the heap (inside the enclosing object), and the inner class accesses it live through the enclosing-instance pointer — there is no copying and therefore no drift problem.