Challenge 3: Reassigning a Captured Local Variable — Possible Solution
====================================================================

Broken attempt — CaptureDemo.java:

import java.util.function.Supplier;

public class CaptureDemo {
    public static void main(String[] args) {
        int count = 5;
        Supplier<Integer> getCount = () -> count;   // captures count

        count = 10;   // reassigning AFTER the lambda captured it

        System.out.println(getCount.get());
    }
}

Representative compile error:

    CaptureDemo.java:6: error: local variables referenced from a lambda
    expression must be final or effectively final
            Supplier<Integer> getCount = () -> count;
                                                ^
    1 error

Explanation:
The lambda captures count by reading its value, but Java requires any
local variable a lambda captures to be "effectively final" -- assigned
exactly once, with no reassignment anywhere in its scope, even outside
the lambda itself. The moment `count = 10;` appears anywhere after
count's initial assignment, count is no longer effectively final, and
the compiler rejects the capture -- it doesn't wait to see whether the
reassignment happens before or after the lambda actually runs.

This is stricter than a JavaScript closure, which can freely reassign
a captured outer variable and have the closure observe the new value.
Java's lambda captures a variable's VALUE at the point of capture (for
a primitive), not a live, mutable reference to the variable itself,
which is exactly why the language refuses to let that value silently
become stale or ambiguous.

WHY THIS WORKS AS AN ANSWER
------------------------------
This reproduces the exact effectively-final violation the chapter's
warn-box describes -- a captured local variable reassigned after the
lambda is defined -- and explains why Java enforces this at compile
time rather than allowing the mutable-closure behavior JavaScript
permits.