Lambdas and functional interfaces

For this lesson, we'll focus on lambdas as Java actually uses them: the functional-interface families, lambda syntax, target typing, compilation with invokedynamic, and the this rule that separates lambdas from anonymous classes. We will link back to Functional interfaces in Java for the broad SAM rule and Functional programming in Java for pure functions and streams, then go deeper on the lambda machinery interviewers probe.

01Picture it first: plugs that learn their socket

A lambda is like a universal plug with no voltage printed on it. The wall socket tells it the shape: Predicate<String> means one String in and one boolean out; Function<String, Integer> means one String in and one Integer out. The same text can fit different sockets if the method shape lines up.

That is the mental model I want you to keep. Lambdas are not little untyped blobs floating around forever; they become real Java objects only when a target functional interface is known.

Fig. 1

A lambda expression is shown as an untyped plug that becomes either Predicate String or Function String Integer when it is connected to a target functional interface socket

Notice the important direction. The variable declaration, method parameter, cast or return type tells the compiler what the lambda is allowed to mean.

02Lambdas under the hood: syntax, shapes and target typing

import java.util.Comparator;
import java.util.function.*;

Predicate<String> blank = s -> s.isBlank();
Function<String, Integer> length = s -> s.length();
Consumer<String> print = System.out::println;
Supplier<Long> now = () -> System.nanoTime();
UnaryOperator<String> clean = s -> s.trim().toLowerCase();
BinaryOperator<Integer> max = (a, b) -> a >= b ? a : b;

var alsoBlank = (Predicate<String>) (s -> s.isBlank());
Comparator<Order> byTotal = (left, right) -> Long.compare(left.totalCents(), right.totalCents());

A lambda expression is poly expression in JLS language, which means its type depends on context. s -> s.length() is not automatically a Function<String, Integer>. Put it in a ToIntFunction<String>, and the result becomes primitive int; put it in a Predicate<String>, and it fails because int is not boolean.

Notice three things:

• The parameter list can be terse or explicit. s -> s.length() is common; (String s) -> s.length() is equivalent when the target type is known. You cannot mix inferred and declared parameters, so (String s, i) -> ... is illegal.
• The body can be an expression or a block. x -> x + 1 returns the expression. x -> { return x + 1; } needs return; x -> { x + 1; } is not a valid statement.
• var works in lambda parameters since Java 11, mostly for annotations: (@Nonnull var s) -> s.trim(). If one parameter uses var, they all must.

Here are the everyday syntax forms I expect a strong candidate to read without pausing.

The trade-off is readability. My default is inferred parameters and expression bodies for one-line transformations, then explicit types or a named method when the reader has to reverse-engineer the shape.

The functional-interface families

You already met the single-abstract-method rule in Functional interfaces in Java. In lambda-heavy code, the practical skill is choosing the right socket quickly.

Function<String, Order> parseOrder = json -> OrderParser.parse(json);
BiFunction<Long, Integer, Long> discount = (cents, pct) -> cents * (100 - pct) / 100;
Supplier<Config> config = () -> Config.load("checkout.yaml");
Consumer<Receipt> sendReceipt = receipt -> mailer.send(receipt.email(), receipt.html());
Predicate<Order> risky = order -> order.totalCents() > 100_000 && order.country().equals("NG");
UnaryOperator<Long> addGst = cents -> cents * 118 / 100;
BinaryOperator<Long> sum = (left, right) -> left + right;

IntPredicate positive = value -> value > 0;
ToIntFunction<String> utf16Length = text -> text.length();
IntUnaryOperator clampPercent = pct -> Math.max(0, Math.min(100, pct));
ObjIntConsumer<Cart> reserve = (cart, quantity) -> inventory.reserve(cart.id(), quantity);

Function<T,R> transforms. Supplier<T> produces with no input. Consumer<T> accepts and returns nothing. Predicate<T> answers yes or no. UnaryOperator<T> is a Function<T,T>, and BinaryOperator<T> is a BiFunction<T,T,T>.

The naming rules are worth memorising because they scale across the package. IntPredicate means the input is primitive int; ToIntFunction<T> means the output is primitive int; ObjIntConsumer<T> means an object plus an int. There are 40-plus interfaces in java.util.function, but these prefixes keep the set predictable.

Target typing in method calls and overloads

Target typing shows up most sharply at method-call boundaries. The compiler checks whether the lambda can implement the single abstract method of the parameter type.

static <T> T firstMatch(List<T> items, Predicate<T> keep) {
    for (T item : items) {
        if (keep.test(item)) return item;
    }
    return null;
}

Order expensive = firstMatch(orders, order -> order.totalCents() > 50_000);

order is inferred as Order because items is a List<Order> and the second parameter is Predicate<T>. That is why changing the receiver type can change the lambda without touching the lambda text.

Many candidates are quick to say "the lambda knows its parameter type". It doesn't. The target type pushes inward, then the lambda body is checked against it.

03How lambdas compile

import java.util.function.LongUnaryOperator;
import java.util.function.Supplier;

public class PricingRules {
    private final long serviceFee = 99;

    Supplier<String> label(String market) {
        return () -> "checkout:" + market;        // captures a local value
    }

    LongUnaryOperator addFee() {
        return cents -> cents + serviceFee;        // captures this
    }

    Runnable whoAmI() {
        return () -> System.out.println(this.getClass().getSimpleName());
    }
}

With normal Java 21 compilation, you get PricingRules.class, not PricingRules$1.class. javac moves lambda bodies into private helper methods and places an invokedynamic instruction at the creation site. The bootstrap method is usually java.lang.invoke.LambdaMetafactory.metafactory, which links a call site that produces an implementation of the functional interface.

Fig. 2

The lambda compilation path shows source code becoming private lambda body methods plus an invokedynamic call site, then LambdaMetafactory linking a hidden class at runtime with no extra inner class file on disk

There are two useful consequences. A non-capturing lambda, like () -> log.info("tick"), can be cached and reused by the runtime because it carries no per-evaluation state. A capturing lambda, like () -> market, needs to remember the captured value, so evaluating the lambda expression usually creates a small object, although the JIT can often remove it when it does not escape.

Do not promise object identity in an interview. The JLS does not require one instance per lambda or singleton reuse. The safe answer is the bytecode shape: invokedynamic, LambdaMetafactory, hidden runtime implementation, no anonymous inner class file.

04Real world: callbacks that stay readable

Here is the split I usually recommend in code review:

orders.stream()
        .filter(this::isReadyForSettlement)
        .map(this::toSettlementCommand)
        .forEach(settlementClient::submit);

private boolean isReadyForSettlement(Order order) {
    return order.isPaid() && !order.isRefunded() && order.totalCents() > 0;
}

The lambda or method reference is now a pointer to business language, not a hiding place. For three simple expressions, inline is fine. When the lambda needs logging, exception handling or comments, name the operation.

05Advanced: this, capture, and anonymous-class differences

Lambdas share the surrounding scope more tightly than anonymous classes do. They can capture local variables only if those variables are effectively final, meaning assigned once and never changed. The lambda captures the value, not a live local variable slot that can keep changing.

class ReceiptPrinter {
    private final String prefix = "receipt";

    Runnable lambdaPrinter(String id) {
        return () -> System.out.println(this.prefix + ":" + id);
    }

    Runnable anonymousPrinter(String id) {
        return new Runnable() {
            private final String prefix = "anonymous";

            @Override public void run() {
                System.out.println(this.prefix + ":" + id);
            }
        };
    }
}

In lambdaPrinter, this.prefix means the ReceiptPrinter field. In anonymousPrinter, this.prefix means the field on the anonymous Runnable object. That one word, this, is the fastest way to tell whether someone understands that lambdas are not anonymous classes in nicer syntax.

Fig. 3

A lambda keeps this bound to the enclosing ReceiptPrinter while an anonymous class has its own this and can hold its own prefix field

There is also a design pitfall. If a lambda is doing domain work that deserves a name, a custom functional interface can be better than Function<Long, Long>.

@FunctionalInterface
interface PriceRule {
    long apply(long cents);

    default PriceRule then(PriceRule next) {
        return cents -> next.apply(apply(cents));
    }
}

The simple option is the standard interface. It stops being enough when the name carries a contract, such as "price rules must be deterministic and use cents". My default: use java.util.function first, then introduce a domain interface when it improves call sites or documents rules the compiler cannot express.

06How to say it in the interview

When I ask this, I'm listening for the bridge between syntax and runtime. I want the one-abstract-method rule, the standard interface families, target typing, the primitive specialisations, and a non-hand-wavy explanation of invokedynamic.

functional interface = exactly 1 abstract method
@FunctionalInterface = compile-time guard

shapes:
  Function<T,R>      T -> R
  BiFunction<T,U,R>  (T,U) -> R
  Supplier<T>        () -> T
  Consumer<T>        T -> void
  Predicate<T>       T -> boolean
  UnaryOperator<T>   T -> T
  BinaryOperator<T>  (T,T) -> T
  IntPredicate / ToIntFunction / IntUnaryOperator = avoid boxing

lambda syntax: params -> expression | params -> { statements }
type comes from target context
compile: lambda body + invokedynamic + LambdaMetafactory
no Outer$1.class for the lambda
this in lambda = enclosing this
this in anonymous class = anonymous object