Functional interfaces in Java

Lambdas arrived in Java 8, and the trick that made them fit into a 20-year-old type system is the functional interface. Java didn't add a "function type" like (Order) -> boolean. It reused interfaces, and said: if an interface has one abstract method, a lambda can stand in for it. Interviewers like this topic because it sits right on the line between syntax and the JVM. Anyone can write x -> x * 2; fewer people can tell you which interface it became, what javac generated, or why forEach won't let them throw an IOException.

For this lesson, we'll focus on the single-abstract-method rule, the java.util.function toolbox, composition, method references, how lambdas compile, checked exceptions, and how to design your own functional interface.

01Picture it first: one socket, many plugs

Think of a functional interface as a wall socket with one specific shape. The socket doesn't care what you plug in, a lamp, a charger, a kettle, as long as the plug matches. Predicate<Order> is a socket shaped "takes an Order, returns a boolean". A lambda, a method reference or a full class can all be plugs, provided their shape fits.

That also explains why the same lambda text can become different types. s -> s.isEmpty() fits Predicate<String> and also Function<String, Boolean>. The lambda has no type of its own; it takes the type of the socket it's plugged into, which the JLS calls the target type.

The standard library ships a whole wall of sockets, grouped by shape. Here's the map I keep in my head:

Fig. 1

A map of the java.util.function families grouped by shape: Function and BiFunction transform, Supplier produces, Consumer accepts, Predicate tests, UnaryOperator and BinaryOperator keep the same type, each with primitive variants such as IntPredicate and ToLongFunction

Notice the naming pattern, because it lets you guess an interface you've never used. Bi means two inputs. A primitive prefix like Int means the input is primitive (IntPredicate.test(int)). To plus a primitive means the output is primitive (ToIntFunction.applyAsInt(T)). Obj plus a primitive mixes an object and a primitive (ObjIntConsumer.accept(T, int)).

02The one-abstract-method rule under the hood

@FunctionalInterface
interface PriceRule {
    long apply(long cents);                      // abstract
    default PriceRule then(PriceRule next) {     // default: doesn't count
        return c -> next.apply(apply(c));
    }
    static PriceRule identity() { return c -> c; } // static: doesn't count
    boolean equals(Object o);                    // Object method: doesn't count
    String toString();                           // Object method: doesn't count
}

interface Auditable {
    void audit();
    void flush();                                // two abstract methods
}

interface RefundRule extends PriceRule {}        // inherits exactly one

PriceRule is functional: one abstract method, apply. Auditable is not, so Auditable a = () -> {} fails with "incompatible types: Auditable is not a functional interface". RefundRule is functional, because it inherits one abstract method and adds none.

Here's the count the compiler does for each of the three, member by member.

Fig. 2

PriceRule's members counted one by one: apply is abstract and counts, while the default, static and re-declared Object methods don't, so the total is one and it is functional; Auditable has two abstract methods and is not functional; RefundRule inherits one and is functional

Notice three things:

• default and static methods have bodies, so they aren't abstract, and a lambda doesn't need to supply them. This is how Function can have andThen and still be a lambda target.
• Re-declaring an Object method doesn't add an abstract method. Every implementation already inherits equals and toString from Object. That's why Comparator declares boolean equals(Object) and is still functional (JLS §9.8).
• @FunctionalInterface changes nothing at runtime. It's a compile-time check plus documentation. Without it, Runnable-style interfaces still work with lambdas; with it, the next person who adds a second abstract method gets a compile error instead of breaking every caller.

Generic methods are the one exception you might hit: an interface whose single abstract method is itself generic (<T> T convert(String s)) is functional, but a lambda can't implement it, because lambdas can't declare type parameters. Only a method reference can.

The families in practice

Predicate<Order>          freeShipping = o -> o.totalCents() >= 50_000;
Supplier<Config>          config       = () -> Config.loadFrom("app.yaml");
Consumer<Receipt>         sendEmail    = r -> mailer.send(r.customerEmail(), r.render());
Function<Order, OrderDto> toDto        = o -> new OrderDto(o.id(), o.totalCents());

BiFunction<Long, Integer, Long> discount  = (cents, pct) -> cents * (100 - pct) / 100;
UnaryOperator<String>           normalise = s -> s.trim().toLowerCase();  // T -> T
BinaryOperator<Long>            add       = Long::sum;                    // (T, T) -> T

ToLongFunction<Order> totalCents = Order::totalCents;   // returns long, no Long box
IntPredicate          isEven     = n -> n % 2 == 0;     // takes int, no Integer box

UnaryOperator<T> extends Function<T, T> and BinaryOperator<T> extends BiFunction<T, T, T>; they exist to make "same type in and out" readable. There's no TriFunction. If you need three inputs, either group them into a record or write your own interface.