Groovy Closure Execution Context Limits

Closure Scope Behavior

When a Groovy closure is created, it captures every variable from its defining lexical scope that is accessed at creation time. Asynchronous execution—whether on another thread, via an executor, or through a GPars async call—does not alter this capture; the closure object remains reachable as long as it is held somewhere.

Confirmed facts

• The closure retains references to all captured variables after the outer method returns, provided the closure object itself stays reachable.
• Mutable captured variables can be modified inside the asynchronous closure, and the change is observable after the defining scope has ended.
• Immutable (final) captured variables remain readable but cannot be reassigned; their values stay constant throughout the closure’s lifetime.
• Thread boundaries do not affect the lexical scope; only the reachability of the closure object matters.

Practical verification steps

1. Define a local variable inside a method, create a closure that reads the variable and also modifies a mutable version of it.
2. Start the closure asynchronously using new Thread({ /* closure code */ }) or an executor.
3. Allow the outer method to return (or let the thread finish) before inspecting the variable’s value.
4. Print the variable after the outer method returns; it should show the original value for immutable captures or the updated value for mutable captures.

Assumptions & uncertainty

We assume the closure runs on a thread that keeps the closure object alive (e.g., a non‑daemon thread). If the closure is stored in a static field or returned from a method, the outer objects must not be garbage‑collected before the asynchronous execution runs, otherwise the captured state may become unreachable.