صياغة Lambda

Written Explanation

The shape

A lambda has three parts, as the Oracle Java Tutorials describe them: a parameter list, the arrow token ->, and a body.

(parameters) -> body

The body is either a single expression or a block in braces. Here is a small functional interface we will use for the examples:

interface Op {
    int apply(int a, int b);
}

Its one abstract method takes two ints and returns an int. Any lambda assigned to an Op must match that shape.

Parameters

You normally leave the types out. The compiler already knows from the target type (Op) that a and b are int, so writing them is repeating yourself. Explicit types are legal, and handy when you want the code to document itself. Do not mix: either type every parameter or none.

Expression body

If the body is a single expression, write it directly. There is no return and no semicolon inside the lambda:

Op add = (a, b) -> a + b;

If the interface method returns a value, the expression's value is the result. If the interface method returns void, the expression is just evaluated for its effect. For example, Runnable r = () -> System.out.println("hi"); is fine, even though println is a call, because Runnable.run returns void.

Block body

When you need several statements, use braces. Now you write statements, with semicolons, and a value-returning lambda must use return:

Op bigger = (a, b) -> {
    if (a > b) {
        return a;
    }
    return b;
};

The braces-and-return form and the expression form are interchangeable when the body is a single statement: (a, b) -> a + b and (a, b) -> { return a + b; } mean the same.

Quick check: does the shape match?

For a lambda to compile, three things must line up with the interface's single abstract method:

1. The number of parameters.
2. The parameter types (inferred or stated).
3. The return: a value of the right type, or nothing if the method is void.

If a lambda does not compile, compare it with the method signature of the interface one piece at a time.

Using variables from outside: capturing

A lambda can read local variables and parameters from the method around it:

int taxPercent = 15;
Op withTax = (price, qty) -> price * qty * (100 + taxPercent) / 100;

This is called capturing. The rule, from the Oracle tutorial and the Java Language Specification: a captured local variable must be final or effectively final, meaning it is never assigned a new value after it is first set. You do not have to write final; you just must never change the variable.

Why such a strict rule? A lambda may run later, or in another thread, long after the method that created it has moved on. A local variable lives in that method's frame, so Java copies the value into the lambda. If the variable could change afterwards, the lambda and the method would see different values, and the code would be confusing. The compiler removes the problem by forbidding the change.

Two errors show this rule. Changing a captured variable inside the lambda:

int count = 0;
names.forEach(n -> count++);

Bad1.java:6: error: local variables referenced from a lambda expression must be final or effectively final

Or changing it anywhere, even outside the lambda, after you have set it:

int limit = 10;
limit = 20;
Runnable r = () -> System.out.println(limit);

Bad2.java:5: error: local variables referenced from a lambda expression must be final or effectively final

Notice that the rule is about local variables. Fields of an object are not subject to it. That does not make it a good idea to change them from a lambda, but it is not a compiler error. The real fix is to restructure: count with a normal loop, or (next module) with a stream operation designed for counting.

No shadowing

A lambda does not create a new scope for names. The parameter of a lambda cannot reuse the name of a local variable that is already in scope:

int x = 5;
Function<Integer, Integer> f = x -> x * 2;

Bad3.java:4: error: variable x is already defined in method main(String[])

Rename the lambda parameter (n -> n * 2).

When a lambda gets too long

A lambda is at its best when it fits on one line. Once it grows to a block of five, ten, or twenty lines, you have a new problem: the logic hides inside an argument list, it has no name, and you cannot test it alone.

The fix is to move the logic into a named method and pass the method (the next lessons show the short syntax for this, method references). A good rule of thumb for this course: if you need braces, ask whether this deserves a name. If the body needs more than three lines, it does.