Given lambdas, method references, local classes, and anonymous classes, how do you decide which to use, and what are the trade-offs of each?
answer
- Ladder: method ref -> lambda -> anonymous -> named local -> member/top
- Lambda: functional interface only, no class extension
- Anonymous: extend class / multiple methods / state / self this
- Named local: constructor, reuse, readable name
- Inner classes capture enclosing instance -> leak risk; prefer static when long-lived
basics
~20 sUse a lambda or method reference when you just need to fill in one method of a functional interface. Use an anonymous class when you must extend a class, implement multiple methods, or keep state. Use a named local class when you need a constructor or reuse it several times in the method.
solid answer
~50 sPick the lightest tool that fits. A lambda (or method reference) is best for a single-abstract-method interface where you only supply that method's body — it's concise, has lexical `this`, and produces no separate class file. Step up to an anonymous class when you need to extend a *class* (lambdas can't), override or add more than one method, hold per-instance fields, or refer to the instance itself via `this`. Promote to a named local class when you want a constructor, want to instantiate it more than once in the method, or just want a readable name in stack traces. Promote further to a member or top-level class when the type is reused outside the method, deserves tests, or grows large. Trade-offs: anonymous/local classes capture the enclosing instance (a potential memory-leak source if the instance is held long-term) and clutter stack traces with Outer$1; lambdas are cleaner but can't self-reference or extend classes; over-using inline classes hurts readability.
go deeper
Knows to prefer a lambda for simple callbacks and that anonymous classes are the older, heavier alternative.
Can list when a lambda is insufficient (extend a class, multiple methods, state) and step up to an anonymous or named local class.
Reasons about the full ladder including capture-based leaks, stack-trace readability, and this semantics when choosing.
Establishes team conventions (default to lambdas/method refs, lift reusable types out, prefer static nested classes for long-lived objects) and reviews for capture-driven leaks and readability.
## The decision ladder Think of four rungs, from lightest to heaviest. Climb only as high as you need: ### 1. Method reference — `Type::method` The most concise option when an existing method already does exactly what the functional interface needs (`list.forEach(System.out::println)`). Zero new logic, maximum readability. Only works for functional interfaces. ### 2. Lambda — `(args) -> body` Use when you need a small inline body for a **functional interface** (exactly one abstract method). Benefits: terse; **lexical `this`** (refers to the enclosing instance); no separate `.class` file; the compiler can often avoid allocating a new object for stateless lambdas. Limits: cannot extend a class; cannot implement an interface with more than one abstract method; cannot reference itself via `this`; can't add fields or extra methods. ### 3. Anonymous class — `new Type() { ... }` Step up when a lambda can't express it: - you must **extend a class** (e.g. `new Thread() { ... }`), - the target interface has **multiple abstract methods**, - you need **per-instance state** (fields) or extra helper methods, - you need the object to **reference itself** via `this` (e.g. a self-deregistering listener). Costs: it captures the enclosing instance (lifetime/leak consideration), produces `Outer$N.class`, and shows as `Outer$1` in stack traces — harder to read. ### 4. Named local class — `class Foo { ... }` inside the method Step up again when you need a **constructor**, want to **instantiate it multiple times** within the method, or simply want a **descriptive name** (clearer stack traces, easier to read). Still scoped to the method, still captures effectively-final locals and the enclosing instance. ### Beyond: member or top-level class If the type is used outside the method, deserves unit tests, or is non-trivial in size, lift it to a (possibly `static`) **member class** or its own file. A `static` member class avoids capturing the enclosing instance, removing that leak risk. ## Cross-cutting trade-offs - **Memory / leaks.** Non-static local, anonymous, and (non-static) member classes hold a reference to the enclosing instance. If such an inner object outlives its enclosing object (e.g. stored in a long-lived registry), it pins the enclosing object in memory. Lambdas that capture `this` do the same; stateless lambdas capture nothing. Prefer `static` named classes when the inner object may be long-lived. - **Readability & diffs.** Inline anonymous classes can bury logic; a named class often reads better and produces smaller diffs when edited. - **Debuggability.** Named classes give meaningful stack frames; anonymous classes give `Outer$1`; lambdas give synthetic `lambda$...` frames. - **`this` semantics.** Covered above: anonymous/local introduce their own `this`; lambdas don't. This affects refactoring direction. - **Reuse.** Lambdas and anonymous classes are single-use expressions; a named class can be instantiated repeatedly. ## Rule of thumb Default to a **method reference**, then a **lambda**; reach for an **anonymous class** only when the language forces you to (extends a class / multiple methods / self `this` / state); reach for a **named class** when you want a name, a constructor, or reuse — and lift it out of the method once it earns independent existence.
- Why can a long-lived anonymous or inner class object cause a memory leak?A non-static inner/anonymous class holds an implicit reference to its enclosing instance. If the inner object is stored somewhere long-lived (a registry, a cache, a static field), that reference keeps the whole enclosing object reachable, so it can't be garbage-collected. Using a `static` named class avoids the implicit reference.
- When is an anonymous class still required over a lambda in modern Java?When you must extend a class, implement an interface with more than one abstract method, keep instance state or extra methods, or reference the created object itself via `this`. Lambdas can't do any of those.
saying these in an interview costs you the question
- Using an anonymous class where a lambda or method reference is clearly cleaner
- Ignoring the enclosing-instance capture as a memory-leak source for long-lived inner objects
- Claiming a lambda can extend a class or implement a multi-method interface
- Reaching for a top-level class for a trivial one-off callback