Sybex 829 Ch 8 Lambdas:Why does it make a difference to the compiler where these lines are inserted?

[Anil Philip]

tb864585.JaSE17SG.c08.10

Boyarsky-Selikoff chapter 8 appendix

Which of the following can be inserted without causing a compilation error? (Choose all that apply.)
public void remove(List˂Character˃ chars) {
   char end = 'z';
// LOCATION A
   Predicate˂Character˃ predicate = c -˃ {
      char start = 'a'; return start ˂= c && c ˂= end; };
// LOCATION B
}

        char start = 'a';
        char c = 'x';
        chars = null;

When these lines are put in LOCATION A, there is a compiler error:

java: variable c is already defined in method remove(java.util.List<java.lang.Character>)
java: variable start is already defined in method remove(java.util.List<java.lang.Character>)

But when the same lines are moved to LOCATION B, there is no error.

Why does it make a difference to the compiler where these lines are inserted?

[Paul Clapham]

The compiler error (or anyway, one of the two) I get in Eclipse is this:

Lambda expression's local variable start cannot redeclare another local variable defined in an enclosing scope.

That's a bit more explanatory than the messages you got. Why you can have a local variable redeclaring a local variable defined in a lambda expression (as per your Location B) but not vice versa (Location A) is a mystery to me but there it is.

Hope that helps.

[Jeanne Boyarsky]

The lambda only cares about things that come before it. When the code is in location A and the lambda comes along, "c" is taken and can't be reused. In location B, the lambda isn't in scope anymore so "c" doesn't produce such a conflict.

[Anil Philip]

Jeanne Boyarsky wrote:The lambda only cares about things that come before it. When the code is in location A and the lambda comes along, "c" is taken and can't be reused. In location B, the lambda isn't in scope anymore so "c" doesn't produce such a conflict.

I thought the scope for Lambdas would be similar to anonymous classes since it is implemented as such?

[Paul Clapham]

Jeanne Boyarsky wrote:The lambda only cares about things that come before it. When the code is in location A and the lambda comes along, "c" is taken and can't be reused. In location B, the lambda isn't in scope anymore so "c" doesn't produce such a conflict.

This is also true if you replace the lambda with an ordinary { ... } code block, so evidently the rule has been around since the beginning of Java. That was something I didn't know because I wouldn't ever have written code with duplicate local variable names like that.