Anonymous callbacks and capture: what runs later?

Trace one-off Java behavior, functional-interface lambdas, and Python closures without confusing creation, capture, and invocation. Methods and type contracts · Object-oriented programming.

You hand a task to another part of a program and expect it to run later. The task might be a Java lambda, an inline Java object, or a Python function. The useful question is not “is this anonymous?” It is “what was created, what did it capture, and when does its body run?”

Create now, run later

A lambda is a short way to write the one method an interface requires: () -> ... means “a method taking nothing that does ...”. Java calls an interface with exactly one abstract method a functional interface, and Job below is one, so a lambda can supply its run method. The scenes show printed output on a Console card. Follow the three moments in order: the callback is created, it captures what it mentions, and a later run() call executes the body.

interface Job {
    void run();
}

StringBuilder prefix = new StringBuilder("A");
Job task = () -> System.out.println(prefix + "-sent"); // created, nothing printed
prefix.append("+");                                      // the same builder changes
task.run();                                              // prints A+-sent

Nothing prints when the lambda is evaluated. The callback holds a link to the StringBuilder that prefix names, so append is visible when the body finally reads it. Java did not freeze the object, because it captured the reference.

Java does insist that the local variable stays put. A local used inside a lambda or an anonymous class must be final or effectively final, meaning it is never reassigned. Writing prefix = new StringBuilder("B"); after the lambda would be a compile error, since the callback would silently keep the old object.

Anonymous class or lambda: whose this?

An anonymous class, written new Job() { ... }, creates one object with no reusable class name. It still has an identity, it can declare its own members, and when it is built inside an instance method it keeps a link to the enclosing object. A lambda is shorter and adds no object-like receiver of its own, so this inside it means the surrounding object.

class Dispatcher {
    String who = "dispatcher";

    void demo() {
        Job anon = new Job() {
            String who = "callback";
            public void run() { System.out.println(this.who); }
        };
        Job lam = () -> System.out.println(this.who);
        anon.run();   // callback
        lam.run();    // dispatcher
    }
}

The anonymous body sees its own who through this. The lambda body has no who of its own, so this.who reads the Dispatcher's. That matters whenever a callback touches instance state: choose a lambda to stay in the surrounding object's context, and an anonymous class when the callback needs state or members of its own.

Python closures look names up when called

A Python lambda is an anonymous function object, and a nested def is a named one; both can travel as callbacks. When the body mentions a name from an enclosing scope, the function keeps a link to the variable's cell, and Python reads the cell when the function is called. Rebinding the variable later therefore changes what the function sees.

late = [lambda: i for i in range(3)]
snap = [lambda i=i: i for i in range(3)]

[f() for f in late]   # [2, 2, 2]
[f() for f in snap]   # [0, 1, 2]

The scenes unroll each comprehension into three assignments and one print.

All three late lambdas link to the one cell for i, and the loop leaves it at 2. Each call reads the cell only now, so every lambda reports 2.

A default argument is evaluated when the lambda is created, so i=i stores the number from that pass inside the function itself. It is a deliberate snapshot, not a rule for every closure. A default that holds a mutable object, such as a list, stores the reference, so later changes to that list still show.

Choose what the callback should see

Decide first whether the callback should observe later changes or keep today's value. To observe changes, capture the object, as in the StringBuilder above. To keep a value as of now, copy it into a new local before creating the callback in Java, such as String now = prefix.toString();, or use a default argument in Python. A button handler registered in a loop, or a timer that reports a setting, is where this timing shows up. Java's single-method interface and effectively-final rule have no Python counterpart, so predict each language by its own rule.

For any delayed call, name three moments: creation, capture, invocation. Then ask which object the captured link reaches and whether anything changed it before the call.

Recap

• A callback is created, captures, and runs later; its body executes only at the call.
• Java captures the value of an effectively-final local, which for an object is the reference, so a mutation shows and a reassignment is rejected. A lambda's this is the surrounding object, while an anonymous object has its own.
• Python closures read the variable's cell when called; a default argument stores a value at creation.

Revisit method receivers and class methods when the callback's receiver matters, and revisit nested types and enclosing scope when you need to name the enclosing object or closure that a callable carries. Continue to exception contracts when a callback can fail and its caller must choose an explicit failure contract. Practise object updates in Linked List Fundamentals, where the operation runs against a concrete node state.