Closure in Java - Captured value - why this unexpected result?

Question

I think I've met this classic situation in JavaScript.

Usually the programmer would expect this code below to print "Peter", "Paul", "Mary".

But it doesn't. Could anyone explain exactly why it works this way in Java?

This Java 8 code compiles OK and prints 3 times "Mary".

I guess it's a matter of how it's implemented deep down
but ... doesn't this indicate a wrong underlying implementation?

import java.util.List;
import java.util.ArrayList;

public class Test008 {

    public static void main(String[] args) {
        String[] names = { "Peter", "Paul", "Mary" };
        List<Runnable> runners = new ArrayList<>();

        int[] ind = {0};
        for (int i = 0; i < names.length; i++){ 
            ind[0] = i;
            runners.add(() -> System.out.println(names[ind[0]]));
        }

        for (int k=0; k<runners.size(); k++){
            runners.get(k).run();
        }

    }

}

On the contrary, if I use an enhanced for loop (while adding the Runnables), the correct (i.e. all the different) values are captured.

for (String name : names){
    runners.add(() -> System.out.println(name));
}

Finally, if I use a classic for loop (while adding the Runnables), then I get a compilation error (which makes perfect sense, as the variable i is not final or effectively final).

for (int i = 0; i < names.length; i++){ 
    runners.add(() -> System.out.println(names[i]));
}

EDIT:

My point is: why is not the value of names[ind[0]] captured (the value it has at the moment I add the Runnables)? It should not matter when I execute the lambda expressions, right? I mean, OK, in the version with the enhanced for loop, I also execute the Runnables later but the correct/distinct values were captured earlier (when adding the Runnables).

In other words, why does not Java always have this by value / snapshot semantics (if I may put it this way) when capturing values? Wouldn't it be cleaner and make more sense?

Answer 1

In other words, why does not Java always have this by value / snapshot semantics (if I may put it this way) when capturing values? Wouldn't it be cleaner and make more sense?

Java lambdas do have capture-by-value semantics.

When you do:

runners.add(() -> System.out.println(names[ind[0]]));

the lambda here is capturing two values: ind and names. Both of these values happen to be object references, but an object reference is a value just like '3'. When a captured object reference refers to a mutable object, this is where things can get confusing, because their state during lambda capture and their state during lambda invocation may be different. Specifically, the array to which ind refers does change in this way, which is the cause of your problem.

What the lambda does not capture is the value of the expression ind[0]. Instead, it captures the reference ind, and, when the lambda is invoked, performs the dereference ind[0]. Lambdas close over values from their lexically enclosing scope; ind is a value in the lexically enclosing scope, but ind[0] is not. We capture ind and use it further at evaluation time.

You are somehow expecting here that the lambda will do a full snapshot of all objects in the entire heap that are reachable through the captured references, but that's not how it works -- nor would that make a lot of sense.

Summary: Lambdas capture all captured arguments -- including object references -- by value. But an object reference and the object to which it refers are not the same thing. If you capture a reference to a mutable object, the object's state may have changed by the time the lambda is invoked.

Answer 2

I would say the code does exactly what you tell him to do.

You create "Runnable"'s which print the name at the position from ind[0]. But that expression gets evaluated in your second for-loop. And at this point ind[0]=2. So the expression prints "Mary".

Answer 3

When you create a lambda expression, you are not executing it. It's only executed in your second for loop, when you invoke the run method of each Runnable.

When the second loop is executed, ind[0] contains 2, therefore "Mary" is printed in the execution of all the run methods.

EDIT:

The enhanced for loop behaves differently because in that snippet the lambda expression holds a reference to a String instance, and String is immutable. If you change String to StringBuilder, you can build an example with an enhanced for loop that also prints the final value of the instances being referenced :

StringBuilder[] names = { new StringBuilder().append ("Peter"), new StringBuilder().append ("Paul"), new StringBuilder().append ("Mary") };
List<Runnable> runners = new ArrayList<>();

for (StringBuilder name : names){
  runners.add(() -> System.out.println(name));
  name.setLength (0);
  name.append ("Mary");
}

for (int k=0; k<runners.size(); k++){
  runners.get(k).run();
}

Output :

Mary
Mary
Mary

Answer 4

it is working perfectly .. while calling the println method the ind[0] is 2 as you are using a common variable and increasing the value of it before the function call. thus it will always print Mary. You can do following instead to check

    for (int i = 0; i < names.length; i++) {
        final int j = i;
        runners.add(() -> System.out.println(names[j]));
    }

this will print all the names as desired

or declare the ind locally

    for (int i = 0; i < names.length; i++) {
        final int[] ind = { 0 };
        ind[0] = i;
        runners.add(() -> System.out.println(names[ind[0]]));
    }

Answer 5

Another way to explain this behavior is to look at what the lambda expression replaces:

runners.add(() -> System.out.println(names[ind[0]]));

is syntactic sugar for

runers.add(new Runnable() {
    final String[] names_inner = names;
    final int[] ind_inner = ind;
    public void run() {
        System.out.println(names_inner[ind_inner[0]]));
    }
});

which turns into

// yes, this is inside the main method's body
class Test008$1 implements Runnable {
    final String[] names_inner;
    final int[] ind_inner;

    private Test008$1(String[] n, int[] i) {
        names_inner = n; ind_inner = i;
    }

    public void run() {
        System.out.println(names_inner[ind_inner[0]]));
    }
}
runers.add(new Test008$1(names,ind));

(The names of the generated stuff doesn't really matter. That dollar sign is just a character often used in the names of generated methods/classes in Java - That's why it is reserved. )

The two inner fields are added, so that the code inside the Runnable can see the variables outside of it; if names and ind were defined as final in the outside code (main method), the inner fields wouldn't be necessary. This is so that the variables can be passed by value, as Brian Goetz explains in his answer.

Arrays are like objects, in that if you pass them to a method that modifies them, they will be modified in the original location too; the rest is just OOP basics. So this is in fact the correct behavior.

Answer 6

Well, before lambda, Java used to have a more strict rule for capturing local/parameter variables in anonymous classes. That is, only final variables are allowed to be captured. I believe this is to prevent concurrency confusions - final variables are not going to change. Therefore if you pass some instances created this way into a task queue and have it executed by another thread, at least you know the two threads are sharing the same value. And a deeper reason is explained by Why are only final variables accessible in anonymous class?

Now, with lambdas, and Java 8, you can capture variables that are "effectively final", which are variables that are not declared final but are considered final by the compiler according to how it's read and written. Basically if you add the final keyword to the declaration of an effectively final variable, the compiler won't complain about it.