7.2 Lambda Expressions, Variable Scopes, and Effectively Final

Lambda Expressions, Variable Scopes, and Effectively Final

A lambda expression is an anonymous function—a block of code with parameters that can be passed around and executed on demand. On the 1Z0-830 exam, you will encounter tricky syntax variations, questions probing parameter type mixing, edge cases regarding the var keyword, the strictly enforced effectively final rule for captured local variables, and the fundamental distinctions between lambda lexical scoping and anonymous inner class scoping.

1. Lambda Expression Syntax Anatomy

A lambda expression consists of three distinct parts:

+-----------------------------------------------------------------------------------------+
|                              LAMBDA EXPRESSION ANATOMY                                  |
|                                                                                         |
|       (String a, String b)         ->               a.concat(b)                         |
|       ────────────────────        ────              ───────────                         |
|          Parameter List        Arrow Token          Lambda Body                         |
+-----------------------------------------------------------------------------------------+

Parameter List Syntax Rules

1. Zero Parameters: Parentheses are strictly mandatory (() -> System.out.println("Hi")).
2. Single Parameter with Inferred Type: Parentheses are optional (s -> s.toLowerCase() or (s) -> s.toLowerCase()).
3. Single Parameter with Explicit Type: Parentheses are strictly mandatory ((String s) -> s.toLowerCase(); String s -> s.toLowerCase() is a compile error).
4. Multiple Parameters: Parentheses are strictly mandatory ((x, y) -> x + y or (int x, int y) -> x + y).
5. No Mixing of Inferred and Explicit Types: Every parameter in the list must either specify an explicit type or be inferred. Mixing is illegal: (String a, b) -> a + b causes a compile error.

// Valid Parameter Variations
Supplier<String> s1 = () -> "Hello";                     // 0 params: () required
Consumer<String> c1 = s -> System.out.println(s);        // 1 inferred param: () optional
Consumer<String> c2 = (s) -> System.out.println(s);      // 1 inferred param with ()
Consumer<String> c3 = (String s) -> System.out.println(s);// 1 explicit param: () required
BiFunction<Integer, Integer, Integer> f1 = (a, b) -> a * b; // 2 inferred params: () required
BiFunction<Integer, Integer, Integer> f2 = (Integer a, Integer b) -> a * b; // 2 explicit params

// INVALID Parameter Syntaxes (Compile-Time Errors)
// Consumer<String> err1 = String s -> System.out.println(s); // ERROR: Missing ()
// BiFunction<Integer, Integer, Integer> err2 = (Integer a, b) -> a + b; // ERROR: Mixed inferred/explicit

2. Using var in Lambda Parameters (Java 11+)

Java 11 introduced the ability to use the local variable type inference keyword var on lambda parameters. This enables adding type annotations (such as @Nonnull) directly to inferred lambda parameters.

Rules for Using var in Lambdas

• All-or-Nothing Rule: If var is used for one parameter, it must be used for all parameters in the parameter list.
• No Mixing with Explicit or Inferred: You cannot mix var with explicit types ((var a, String b)) or with bare inferred names ((var a, b)).
• Parentheses Mandatory: Whenever var is used, the parameter list must be enclosed in parentheses, even if there is only a single parameter: (var s) -> s.length() is valid; var s -> s.length() causes a compile error.

// Valid Java 11+ var Usage in Lambdas
BinaryOperator<String> concat = (var a, var b) -> a + b;
Consumer<String> printNonNull = (@Deprecated var s) -> System.out.println(s);
UnaryOperator<Integer> doubler = (var x) -> x * 2;

// INVALID var Syntaxes (Compile-Time Errors)
// (var x, int y) -> x + y;       // ERROR: Cannot mix var with explicit types
// (var x, y) -> x + y;           // ERROR: Cannot mix var with bare inferred types
// var x -> x.toLowerCase();      // ERROR: Parentheses required when var is used

3. Lambda Body Syntax: Expression vs. Block Bodies

A lambda body can be either a single expression or a statement block ({ ... }).

+-----------------------------------------------------------------------------------------+
|                        EXPRESSION BODY vs. BLOCK BODY COMPARISON                        |
|                                                                                         |
|  Expression Body:   (a, b) -> a + b                                                     |
|                     (No braces, NO semicolon, NO return keyword)                        |
|                                                                                         |
|  Block Body:        (a, b) -> { return a + b; }                                         |
|                     (Braces required, semicolon required, explicit return required)     |
+-----------------------------------------------------------------------------------------+

Critical Rules for Lambda Bodies

1. Expression Body: Evaluates to a value or void. Do not include the return keyword or trailing semicolons inside an expression body.
   • Valid: (a, b) -> a + b
   • Invalid: (a, b) -> return a + b; (compile error)
2. Block Body with Non-Void Return: If the functional interface method expects a return value, every control-flow path in the block body must end with an explicit return statement or throw an exception.
   • Valid: (a, b) -> { return a + b; }
   • Invalid: (a, b) -> { a + b; } (compile error: not a statement & missing return)
3. Block Body with void Return: An explicit return; is optional.
   • Valid: s -> { System.out.println(s); }
   • Valid: s -> { System.out.println(s); return; }

4. Lexical Scoping: Lambdas vs. Anonymous Inner Classes

A critical distinction on the certification exam is how variable scopes, shadowing, and the this keyword operate inside a lambda expression compared to an anonymous inner class.

1. Lambdas Do NOT Introduce a New Scope

A lambda expression executes in the exact same lexical scope as its enclosing block. As a result:

• A lambda parameter cannot reuse the name of any local variable declared in the enclosing scope.
• Doing so causes a variable redeclaration compile-time error.

public void processOrder() {
    int count = 100;
    
    // COMPILE ERROR: Variable 'count' is already defined in scope 'processOrder()'
    // Consumer<Integer> consumer = count -> System.out.println(count);
    
    // LEGAL: Using a distinct parameter name
    Consumer<Integer> validConsumer = c -> System.out.println(c + count);
}

2. Anonymous Inner Classes DO Introduce a New Scope

An anonymous inner class creates a distinct nested class scope. Therefore, parameter names or field declarations inside the anonymous class can shadow local variables or fields of the enclosing class.

public void processOrder() {
    int count = 100;
    
    // LEGAL in Anonymous Inner Class: 'count' parameter shadows outer local variable
    Consumer<Integer> inner = new Consumer<Integer>() {
        @Override
        public void accept(Integer count) {
            System.out.println(count); // Refers to parameter 'count'
        }
    };
}

3. Semantics of this and super

• Inside a Lambda: The this keyword refers to the enclosing class instance where the lambda is defined. Lambdas have no independent this identity.
• Inside an Anonymous Inner Class: The this keyword refers to the anonymous inner class instance itself. To access the enclosing instance, you must use qualified this syntax (EnclosingClass.this).

public class ScopeDemo {
    private String name = "Enclosing";

    public void testScopes() {
        Runnable lambda = () -> {
            // 'this' refers to ScopeDemo instance
            System.out.println(this.name); // Prints "Enclosing"
        };

        Runnable anonymous = new Runnable() {
            private String name = "Inner";
            @Override
            public void run() {
                // 'this' refers to the anonymous Runnable instance
                System.out.println(this.name);             // Prints "Inner"
                System.out.println(ScopeDemo.this.name);   // Prints "Enclosing"
            }
        };
    }
}

5. Variable Capturing and the Effectively Final Rule

When a lambda expression or anonymous inner class accesses a local variable declared in its enclosing method or constructor, it captures that variable. Java enforces strict rules on captured variables to ensure memory consistency across threads.

Definition of "Effectively Final"

A local variable or method parameter is effectively final if its value is never modified after it is initialized, even if it lacks the explicit final keyword.

public void checkEligibility() {
    int threshold = 50; // Effectively final because it is never reassigned
    Predicate<Integer> checker = score -> score >= threshold; // LEGAL
    
    int modifier = 10;
    modifier = 20; // Reassigned! modifier is NOT effectively final
    
    // COMPILE ERROR: Local variable 'modifier' defined in an enclosing scope must be final or effectively final
    // Predicate<Integer> invalidChecker = score -> score >= modifier;
}

Mutating Local Variables Inside a Lambda

A lambda expression cannot modify any captured local variable:

public void countMatches(List<String> list) {
    int matches = 0;
    // COMPILE ERROR: Cannot assign a value to final variable 'matches' inside lambda
    // list.forEach(s -> { if (s.startsWith("A")) matches++; });
}

Instance Fields vs. Local Variables

[!IMPORTANT] The effectively final restriction applies strictly to local variables and method parameters. Instance fields (this.field) and static class variables are not subject to the effectively final constraint and can be both read and mutated inside lambda expressions.

public class Accumulator {
    private int total = 0; // Instance field

    public void process(List<Integer> numbers) {
        // LEGAL: Modifying instance field inside lambda
        numbers.forEach(n -> this.total += n);
    }
}

Object Reference Immutability vs. Object State Mutation

If a lambda captures an effectively final reference to a mutable object (such as a List or a custom POJO), the reference itself cannot be changed, but the internal state of the referenced object can be mutated:

public void collectItems() {
    final List<String> resultList = new ArrayList<>(); // Reference is final
    
    // LEGAL: Mutating internal state of resultList
    Consumer<String> collector = s -> resultList.add(s);
    collector.accept("Java 21");
    
    // COMPILE ERROR if you try to reassign the reference itself:
    // Consumer<String> badCollector = s -> { resultList = new ArrayList<>(); };
}