How Do Lambda Expressions Work in Java?

A lambda is an implementation of a functional interface — an interface with exactly one abstract method. It has three parts: the parameter list, an optional arrow, and the body.

The parameter list may be empty, may name each parameter with a type, or may omit the types entirely — but it may not mix the two. The body is either a single expression or a block. An expression body is the value of the lambda; a block body needs an explicit return if the functional method returns a value.

The key mechanism is target typing. A lambda on its own has no type. It only becomes meaningful when it is assigned to a variable, passed as an argument, or returned from a method — and in each of those places the compiler knows the expected type. The compiler then checks that the lambda's parameters and body are compatible with the single abstract method of that interface. That is why (a, b) -> a + b compiles in one place and not another: the target type supplies the parameter types and the return type.

At run time a lambda is not an object you can cast to an interface the compiler does not know about in advance. The JVM creates an implementation of the functional interface, and the instance is created when the expression is evaluated. That is also why a lambda cannot reference this from the enclosing class in the way an anonymous class does — inside a lambda, this refers to the enclosing instance, not to a new anonymous object.

Because the lambda's shape is entirely determined by the target type. If the functional interface declares apply(String s), the lambda must accept exactly one String and return whatever apply returns. The compiler checks this against the interface's single abstract method, and any mismatch is a compile error with a message that points at the functional interface method.

Three mismatches are common. The wrong number of parameters — a lambda with two parameters assigned to a one-argument method is rejected. The wrong types — although a lambda parameter may omit its type, if you write one it must match exactly, with no widening. And the wrong return type — an expression body must produce a value compatible with the method's return type, and a block body needs a return statement when the method is not void.

import java.util.function.BiFunction;
import java.util.function.Function;
import java.util.function.Supplier;

public class Main {
    public static void main(String[] args) {
        Function<String, Integer> length = s -> s.length();
        System.out.println("length of 'hello' : " + length.apply("hello"));

        // The target type decides how many parameters there are.
        BiFunction<Integer, Integer, Integer> sum = (a, b) -> a + b;
        System.out.println("sum of 2 and 3     : " + sum.apply(2, 3));

        // A block body needs an explicit return.
        Function<String, Integer> block = s -> {
            int n = s.length();
            return n * 2;
        };
        System.out.println("doubled length     : " + block.apply("hello"));

        // A zero-parameter lambda for a Supplier.
        Supplier<String> greeting = () -> "hello from a supplier";
        System.out.println("supplier           : " + greeting.get());
    }
}

The output shows the same lambda syntax adapting to four different target types — one argument, two arguments, a block body and no arguments — because each assignment supplies a different interface.

One exception to the strictness is worth knowing: when the parameter types are omitted, the compiler infers them from the target, and that inference does allow the argument types to be exactly what the interface declares. But if you write the type explicitly, it has to be the declared type — you cannot write a supertype and rely on the compiler to narrow it.

A related point about the body. An expression body is implicitly returned, so s -> s.length() returns an int. A block body is a normal block, so it needs return for a non-void method, and it can contain multiple statements and local variables. Mixing the two forms in one lambda is not allowed.

A lambda with no parameters uses empty parentheses: () -> expression. The parentheses are required — you cannot write -> expression on its own.

A method reference is the shorthand for a lambda that calls an existing method. You write the method name followed by :: and, optionally, the receiver. String::length means "take the argument and call length on it". "hello"::toUpperCase means "call toUpperCase on this specific object".

import java.util.function.Function;
import java.util.function.Supplier;

public class Main {
    public static void main(String[] args) {
        // A zero-argument lambda.
        Supplier<String> supplier = () -> "from a supplier";
        System.out.println("supplier : " + supplier.get());

        // A method reference to an instance method of the argument.
        Function<String, Integer> length = String::length;
        System.out.println("length   : " + length.apply("tutorsbot"));

        // A method reference to an instance method of a bound object.
        Supplier<String> upper = "hello"::toUpperCase;
        System.out.println("bound    : " + upper.get());

        // A constructor reference.
        Supplier<java.util.ArrayList<String>> list = java.util.ArrayList::new;
        System.out.println("new list : " + list.get().size());
    }
}

The output shows the two styles side by side. The supplier lambda produces a value from nothing, the method reference applies length to whatever argument it is given, the bound reference calls toUpperCase on a fixed string, and the constructor reference creates an empty ArrayList.

The practical difference is readability rather than behaviour — a method reference and the equivalent lambda compile to the same thing. The rule of thumb most teams use is that a method reference is better when the lambda is nothing more than a call to an existing method, and a lambda is better when there is any logic in the body at all. list.forEach(System.out::println) reads better than list.forEach(s -> System.out.println(s)); list.removeIf(s -> s.length() > 3) is the right form because it contains a condition.