0

In Java, it is only possible to capture final (or effectively final) variables in lambda expressions. It is possible to declare a final variable first and then initialize it once, but not if the initialization occurs in a lambda expression. This is ok:

final int num;
num = 10;

But this is not:

final int num;
Thread thread = new Thread(() -> {
    num = 10;
});
thread.start();

Even if run() is used which doesn't create new threads, it doesn't compile, neither will any other lambda expression. This makes sense since you could execute lambda expressions multiple times, which would mean trying to reassign a final variable.

But it seems like it could be useful to initialize variables in a lambda expression e.g. Maybe you have some long process to get and store a value in a variable like reading a large file; but because it is long, you want it to happen in a new thread, so the current one can move on.

The only solution I know is to define the variable as a one-element array, which allows you to change the element. This seems to me somewhat unintuitive and like a way to cheat the language instead of writing good code. Are there better designs which are good for attacking this problem?

Alexander Ivanchenko
  • 25,667
  • 5
  • 22
  • 46
John Smith
  • 47
  • 4
  • 1
    The problem with your code as shown is that the variable `num` may not exist by the time `thread` executes -- the stack may have been popped due to return from the method declaring `num`. Thus you can't write code to change it. When the variable is final, however, its value can be effectively **copied** into the thread before the thread starts. – access violation Jul 08 '22 at 22:59
  • 1
    If you are going to have a thread that you want to get a result back from, you should use a Callable, ExecutorService, fork join framework, CompletableFuture, or some other constructs and not just expect it to set a local variable in your code. One good way would be to pass in a concurrent queue that it could write to, and your code could read from. – David Conrad Jul 08 '22 at 23:00
  • Oh that makes a lot of sense, I had read of callable and futures but not properly learnt them yet. Thanks both comments helped a lot. – John Smith Jul 08 '22 at 23:48

3 Answers3

2

The best fit for your example is to submit() a Callable to an ExecutorService. Later, when you need the result, you access it via the resulting Future.

Alternatively, if the result is not needed in the main thread, and can be handled asynchronously, you can compose a CompletableFuture to perform your task.

erickson
  • 265,237
  • 58
  • 395
  • 493
2

Even if run() is used which doesn't create new threads, it doesn't compile, neither will any other lambda expression. This makes sense since you could execute lambda expressions multiple times, which would mean trying to reassign a final variable.

Inside a lambda expression, you can initialize variables in the enclosing code. You can use only effectively final variables inside lambda expressions. It's not only related to lambdas, the same applies to anonymous classes and that restriction exists from the earlier days of Java. Java 8 only brought us the notion of effectively final variables.

Here's a simplified answer:

I guess you know that there are two memory areas: the heap where all objects reside and a stack in which is meant to keep the data related to each method call.

Variables related to a particular method call form a layer of the stack, i.e. when a method is being called a new layer gets allocated on the top of the stack, when it calls another method - another layer gets allocated on top of this layer. Even when a variable is being passed around between different layers, each stack layer has its own version of this variable and their values are completely independent. When a method terminates all its layer is being deallocated, and we're loosing access to all its variables, the layer beneath becomes active.

Lambda as well as an instance of the anonymous class are objects that reside in the heap. If there's at least one reference that leads to them on any of the layers of the stack, they would be alive and can sustain much longer than variables of the layer where they have been created. Therefore, it would have no sense if we imagine that it would be allowed to change a local variable from an anonymous class or lambda expression because there's no guarantee that these variables would exist at the moment.

When a lambda or anonymous class is being created, JVM creates a copy of everything that is accessible. If a local variable has not been initialized, it would not be captured because it's not effectively final.

You can find a very simple definition of effectively final variable at the very end of the paragraph 4.12.4. of the Java language specification

If a variable is effectively final, adding the final modifier to its declaration will not introduce any compile-time errors. Conversely, a local variable or parameter that is declared final in a valid program becomes effectively final if the final modifier is removed.

If variable isn't initialized at neither at the moment of declaration, no anywhere in the code, then if you would try to add final modifier to its declaration, it'll cause a compilation. Such variable is not effectively final.

The only solution I know is to define the variable as a one-element array, which allows you to change the element.

If a reference to the object doesn't get changed (i.e. a local variable pointing to the object doesn't change after initialization) we can use this object inside the lambda expression. While creating a lambda, JVM will capture a reference to such object (note: since it's an object, no copies would be created, the JVM would capture the reference to the object itself), and this object would be alive at least while the object representing a lambda is alive. In case when object is mutable (array, collection, etc.) we can modify it, and these changes can be observed in other peaces of the code that possess the reference to the same object (but it's not guaranteed if a non-thread-safe object is being accessed concurrently).

Also note that if a non-synchronized object like an array is being simultaneously modified and accessed for reading from different threads, there's no guaranty the data that has been read is correct. For such cases, have a look at the classes from the package java.util.concurrent.atomic.

Alexander Ivanchenko
  • 25,667
  • 5
  • 22
  • 46
1

Better designs use purpose-built features, such as a CompletableFuture. This provides mechanisms for the asynchronous code to set a return value, for the consumer of the value to (optionally) wait and get the return value, or for subsequent operations to be invoked when the return value becomes available.

access violation
  • 517
  • 2
  • 4