Lambda Expressions in Java — Syntax, Scoping, and invokedynamic

A lambda expression is a concise way to write an instance of a functional interface — an interface with exactly one abstract method. Java 8 introduced them to make callbacks, comparators, and stream operations far more readable than anonymous inner classes.

Syntax

• (params) -> expression for single-expression bodies
• (params) -> { statements; } for block bodies
• One parameter? parens optional: s -> s.length()
• No parameters? () -> doSomething()
• Java 11+: var in parameters allows annotations: (@NonNull var s) -> ...

Target typing

• The compiler infers the lambda's type from context
• The lambda's signature must match the functional interface's single abstract method
• Same lambda, different context: s -> s.length() is Function here, ToIntFunction there

Lambda vs anonymous class — they're not the same

• this in a lambda refers to the enclosing class instance; in an anonymous class it refers to the inner instance
• No new class file per lambda; anonymous classes generate Outer$1.class
• Lambdas compile to invokedynamic instructions backed by LambdaMetafactory
• Lambdas are lazy: the implementation class is generated on first use
• Non-capturing lambdas are cached — zero allocation per call
• Capturing lambdas allocate one instance per capture

The `invokedynamic` mechanism

• javac extracts the lambda body into a synthetic static method
• At the use site, emits invokedynamic with LambdaMetafactory.metafactory as the bootstrap
• First execution: JVM generates a class implementing the functional interface, caches the call site
• Subsequent calls: cached, fast
• Result: smaller JARs, faster startup, better JIT optimization

Variable capture rules

1. Effectively final local variables only

• Either declared final or never reassigned after initialization
• Compile error if you try to reassign a captured local
• Why: lambdas may run later on different threads; capture-by-value avoids race conditions

2. Instance and static fields

• Freely readable and writable from a lambda
• But mutating shared state in parallel streams is a race condition; use collectors

3. Workaround for mutable capture

• AtomicInteger for counters: counter.incrementAndGet()
• One-element array: int[] counter = {0}; then counter[0]++
• Both are code smells — prefer immutable patterns

4. `this` is lexical

• Always refers to the enclosing class instance
• Not the lambda itself; lambdas don't have their own this

When to use lambdas

• Stream operations, comparators, event handlers, callbacks
• Strategy pattern with Map>
• Functional builders, lazy initialization
• Body fits in a few lines; longer bodies should be extracted methods

When NOT to use lambdas

• Body is more than ~5–10 lines (extract a method)
• Need to override multiple methods or extend a class (use anonymous or named class)
• Need the inner instance's this (use anonymous class)
• Complex business logic that deserves a name and unit tests

Common pitfalls

• Effectively-final compile error — don't reassign captured locals; use a wrapper if you really need mutation
• `this` confusion — lambda this is the outer class, not the lambda
• Checked exceptions — standard functional interfaces don't declare them; wrap in RuntimeException, define a custom interface, or use a sneaky-throw helper
• Capturing mutable state in parallel streams — race conditions; use collectors

Recommendation: Use lambdas as the default for any single-method interface implementation — they're cleaner, faster to start (lazy class generation), and play well with the JIT. Reach for method references (User::getName) when the lambda is just calling an existing method; they read better and are sometimes marginally faster. Reserve anonymous classes for the cases lambdas can't handle: extending a class, overriding multiple methods, or needing the inner instance's this. Keep lambda bodies short — if it's longer than a few lines, extract a named method; you gain a stack-trace-friendly symbol and a test target. Always remember `this` is lexical in a lambda and captured locals must be effectively final — these two rules catch most newcomers and are the source of subtle bugs in async code.