Java lambdas and effectively final locals.

Closures and captured variables showed that a Java lambda keeps a copy of each local variable it uses. This lesson looks closer: when the copy is taken, what it means for a reference, and what a lambda keeps when it uses a field.

Below, note is a Supplier<String>: an interface from java.util.function whose method get takes nothing and returns a String. The type in angle brackets is the type that get returns. When the line that makes note runs, Java copies 2 and "oat milk" into the new lambda object. Calling note.get() later runs the body with those copies; the lambda never reads main’s variables again.

Because the lambda holds copies, javac requires each local it uses to be effectively final: set once, and never assigned again anywhere in the method. The check covers the whole method, so an assignment before the lambda counts as much as one after it. Method parameters follow the same rule.

A lambda copies each local it uses when it is made, and javac requires those locals never to be assigned twice anywhere in the method.

A copy of a reference leads to the same object. So a lambda that captured a list can add to it, and the method sees the change. Consumer<String> is an interface whose method accept takes a String and returns nothing.

The rule stops assignments to the variable, not changes to the object. javac refuses an assignment wherever it is: before the lambda, after it, or inside its body. Each one gives the same error, and the mark is under the use of the variable inside the lambda, not under the assignment:

error: local variables referenced from a lambda expression must be final or effectively final

An assignment inside the body, such as cartons = cartons + 1, is reported once for each use of cartons in the lambda.

There are three honest fixes, and each one means something different. If the value is final by the time the lambda is made, copy it into a new local, such as final int count = cartons;, and capture count. If the lambda must keep the contents of an object as they are now, capture a copy of the object, such as List.copyOf(shopping), which Java final, primitives, and boxing introduced. If the lambda must change a value that other code reads, the value belongs in a field, as the next section shows.

Effectively final stops assignments to a captured variable; the object it refers to can still change.

A field is not a local variable, so a lambda does not copy it. When a lambda in an instance method uses a field such as openings, it uses this.openings, and it captures this: the reference to the current object. this is never assigned, so the rule is met, and the lambda reads and changes the field every time it runs. A static field is not captured at all: the lambda reads it from the class each time. Runnable, from java.lang, is the interface whose method run takes nothing and returns nothing.

So the honest place for a count that a lambda updates is a field of the object that owns the count.

Two workarounds are common. int[] opened = {0} is an array of one: the lambda captures the reference and changes opened[0]. AtomicInteger, from java.util.concurrent.atomic, is an object that holds an int; its method incrementAndGet adds 1 safely even when several threads call it at once. Both compile. Both are smells: signs that the design needs a second look. The array hides changing, shared state behind a variable that looks fixed, and its count is lost when the method returns unless something returns the array too. AtomicInteger also tells every reader that threads are involved, even when they are not. When the count belongs to an object, make it a field of that object. When it is a total over a list, a for loop with a plain int is clearer.

A lambda copies this, never a field: it reads and changes each field when it runs.

Before Java 8, code passed behavior with an anonymous class: a class with no name, declared and used in one expression, such as new Supplier<String>() { public String get() { … } }. It looks like a longer lambda, but it is a new class, and that changes what names mean inside it.

In a lambda, names mean what they mean in the method around it. this is the enclosing object. A lambda parameter cannot reuse the name of a local of that method: next to int n, the lambda n -> n + 1 gives error: variable n is already defined in method main(String[]).

In an anonymous class, this is the anonymous object itself. Its methods may declare names that hide outer ones, and it can have fields of its own. To reach the enclosing object, write the class name before this, as in Fridge.this. An anonymous class made in an instance method also keeps the enclosing object in a hidden field, this$0.

In the code below, getClass().getName() returns the name of an object’s class. javac names the first anonymous class inside Fridge Fridge$1.

In a lambda, this is the enclosing object; in an anonymous class, this is the anonymous object, and Fridge.this is the enclosing one.

A lambda has no type of its own. It takes the type of a functional interface: an interface with exactly one abstract method. The code around the lambda decides which interface, and other code runs the lambda by calling that method. java.util.function has the common ones, and Runnable is in java.lang. T and R stand for the types written in the angle brackets:

• Runnable: run() takes nothing and returns nothing.
• Supplier<T>: get() returns a T.
• Consumer<T>: accept(T) returns nothing.
• Function<T, R>: apply(T) returns an R, so a Function<String, Integer> takes a String and returns an Integer.
• Predicate<T>: test(T) returns a boolean.

A method reference turns an existing method into such a value, without calling it. String::length can be a Function<String, Integer>, and shopping::add a Consumer<String>.

A method reference that names an object, such as current::label, evaluates current once, when the method reference is made, and keeps the object it found. So current need not be effectively final, and a later assignment to current does not reach the method reference. The lambda () -> current.label() uses the local current in its body, so javac requires current to be effectively final.

object::method keeps the object it found when it was made, even if the variable is assigned later.

Each bug below follows from a rule in this lesson.

A counter in an array of one. int[] opened = {0}; with a lambda that runs opened[0]++ compiles and counts. But the count lives in an array that only this method and the lambda can reach, each call to the method starts a new count, and the variable looks fixed while its contents change. AtomicInteger hides the same thing and suggests threads. Give the count an owner: a field of the object it belongs to.

A lambda made in a classic for loop. In for (int i = 0; i < 3; i++), a lambda cannot use i, because i++ assigns it. Copy it inside the body, int shelf = i;, and capture shelf, a new local on each pass. The enhanced for loop, for (String item : items), makes a new item on each pass, so it needs no copy.

A field that changes before the lambda runs. A lambda that uses a field reads it when it runs, not when it was made, so plans and retries made from a field all see its latest value. When the lambda must keep the value from the moment it was made, copy the field into a local first.

A large object kept alive. A listener is a function that another object stores and calls when something happens. A listener lambda that uses one field keeps this, and with it everything this refers to. An anonymous class keeps this$0 even when it uses nothing. While a long-lived object stores the listener, all of that stays reachable. Copy the field you need into a local, prefer a lambda, and remove listeners you no longer need.

Give a changing count an owner, copy a loop counter inside the body, copy a field when its current value must be kept, and capture only what the lambda needs.

One lambda uses a copied local, one uses a static field, and one is a method reference on the value of that field. Decide when each one reads mode.