Functional Interfaces in Java — Single Abstract Method Contracts

A functional interface is any interface with exactly one abstract method — the SAM rule. That's the only requirement. It can have any number of default, static, private (Java 9+), and Object-overriding methods, none of which count toward the SAM.

The SAM rule — what counts and what doesn't

Counts:

• Abstract methods declared by the interface

Doesn't count:

• default methods (have implementation)
• static methods (belong to the interface)
• private methods (helpers, Java 9+)
• Overrides of Object methods (equals, hashCode, toString)

This is why Comparator is a functional interface despite having many methods — only compare(T, T) is abstract.

`@FunctionalInterface` annotation

• Optional — the compiler treats SAM-compliant interfaces as functional whether you annotate or not
• Recommended for intentionally functional interfaces:

  • Documents intent
  • Compiler enforces the SAM rule — adding a second abstract method becomes a compile error
  • Catches the mistake at the interface, not at every lambda use site
• Don't annotate interfaces that happen to be SAM but aren't meant to be functional (like Closeable)

Standard library — use these first

Core four in java.util.function:

• Function — transforms T to R
• Predicate — returns boolean
• Consumer — returns void
• Supplier — no input, returns T

Two-argument variants: BiFunction, BiPredicate, BiConsumer

Same-type operators: UnaryOperator, BinaryOperator

Primitive specializations (avoid boxing): IntFunction, ToIntFunction, IntPredicate, etc.

Pre-existing functional interfaces: Runnable, Callable, Comparator — work seamlessly with lambdas.

Default methods enable composition

• Function.andThen, Function.compose, Function.identity()
• Predicate.and, or, negate, Predicate.not(...) (Java 11+)
• Comparator.comparing, thenComparing, reversed
• This is why functional interfaces with one abstract method can still expose a rich API

When to define a custom functional interface

1. Need a checked exception

• @FunctionalInterface interface ThrowingFunction { R apply(T t) throws Exception; }
• Standard Function doesn't declare exceptions — forces lambda authors to wrap

2. More than two parameters

• Standard library stops at Bi* — define a TriFunction if you need three

3. Domain-meaningful name

• RetryPolicy reads better than BiPredicate
• Even if structurally equivalent, the name documents intent at every use site

4. Domain-specific default methods

• Add convenience methods like serializeAll(collection) that build on the SAM

Pitfalls

• Confusing 'one method' with 'one abstract method' — defaults and statics don't count
• Boxing overhead — Function boxes; use IntUnaryOperator in hot paths
• Over-customizing — don't define MyFunction when Function works
• Overly clever interfaces — if a functional interface has 5+ default methods, consider a regular interface or abstract class
• Forgetting `@FunctionalInterface` on intentionally functional interfaces — a future maintainer might break the contract

Recommendation: Always start by checking if a standard java.util.function interface fits — 90% of the time it does. Add `@FunctionalInterface` to any interface you intentionally design for lambda use; it costs nothing and prevents accidental breakage. Define a custom interface only when you have a specific reason: a checked exception, more than two parameters, a domain-meaningful name, or domain-specific defaults. Use primitive specializations (IntFunction, ToIntFunction) in performance-sensitive paths to avoid boxing. Lean on default methods for composition — they're the secret ingredient that makes Java's functional interfaces ergonomic. The pattern is: keep the SAM small and abstract, layer convenience as defaults, use the annotation as a guardrail.