Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #21169

Re: Why is that in JDK8: value used in lambda expression shuld be effectively final?

Show all headers | View raw

On 02.01.2013 15:15, Steven Simpson wrote:
> On 02/01/13 12:51, jeti789@web.de wrote:
>> I'm currently plaing with JDK8 and using
>> lambda-8-b69-windows-i586-17_dec_2012. I wonder why this does not
>> compile:
>>
>> List<Integer> ints = new ArrayList<>();
>> ints.add(1);
>> ints.add(2);
>> ints.add(3);
>>
>> int sum = 0;
>> ints.forEach(i -> {sum += i;});
>>
>> The compiler error is "value used in lambda expression shuld be
>> effectively final"
>
> It's the same reason why inner classes can't mutate local variables in
> the enclosing scope.  The method that accepts the lambda or inner class
> instance cannot formally make any guarantee not to invoke the supplied
> code in a non-serial way.

I don't think concurrency is the main reason.  It has more to do with 
the complexity involved in keeping the surrounding scope (local 
variables on the stack) alive for an _indefinite amount of time after 
the invocation of a method_.  For mutations of references or POD values 
in the surrounding scope this scope would need to stay around for as 
long as the inner / anonymous class instance lives.  In this case

public Runnable sample(int count) {
   return new Runnable() {
     public void run() {
       while ( count > 0 ) {
         --count;
       }
     }
   };
}

variable "count" would need to be assignable at least as long as the 
created instance lives.  Same for any local variable declared inside the 
method body.  If it weren't we would not have proper closure semantics 
(e.g. when returning two instances which refer the same variable from 
the scope).  Since the scope need to be kept for longer, it cannot 
reside on the stack.  That would introduce two different ways of local 
variable access: one via the stack and one via some reference on the 
heap.  I guess since variable access is such a fundamental feature 
language designers did not want to introduce this type of complexity. 
(There could also be performance issues lurking.)

With "final" variables it's easy: just copy all used values or 
references in hidden member variables of the created instance and be 
done.  Because original variables are final the scope does not need to 
be kept around: since state of variables in the scope cannot change both 
values cannot digress.  And actually this is what is happening, as you 
can see when disassembling code.

Example at github because the disassembly output is quite long.
https://gist.github.com/4478864

The member is declared in line 140 and the constructor in 146.  Also you 
can see that the value of this field is used in line 195.

This does not change in Java 8 because compatibility with old code was 
intended.  lambdas are merely syntactic sugar for "old" Java features. 
For anyone interested in the details I recommend to read

http://cr.openjdk.java.net/~briangoetz/lambda/collections-overview.html

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Why is that in JDK8: value used in lambda expression shuld be effectively final? jeti789@web.de - 2013-01-02 04:51 -0800
  Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Steven Simpson <ss@domain.invalid> - 2013-01-02 14:15 +0000
    Re: Why is that in JDK8: value used in lambda expression shuld be   effectively final? Robert Klemme <shortcutter@googlemail.com> - 2013-01-07 23:08 +0100
  Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-02 09:46 -0800
  Re: Why is that in JDK8: value used in lambda expression shuld be effectively final? Saxo <jeti789@web.de> - 2013-01-05 07:01 -0800

csiph-web