Functional Interfaces

A functional interface is an interface with exactly one abstract method. Everything else in it may be default or static, but the single abstract method is what makes it usable as the target of a lambda expression or a method reference.

public class Main {
    public static void main(String[] args) {
        java.util.function.Function<String, Integer> len = s -> s.length();
        java.util.function.Predicate<String> longWord = s -> s.length() > 2;
        System.out.println(len.apply("hello"));
        System.out.println(longWord.test("hi"));
        run(() -> System.out.println("done"));
    }

    static void run(Runnable task) { task.run(); }
}

The example shows the three things you can do. The length function is written as a lambda, an expression that takes a string and returns its length. The predicate is a lambda that answers a yes or no question, and it returns false for a two-letter word. The Runnable is passed as a block of behaviour to a method that knows only the contract, and the output shows the task running.

Because the interface declares the types, the lambda does not need annotations or a return type in most cases. The compiler infers the parameter types and the return type from the target, which is why a lambda can only be used where a functional interface is expected.

The standard library supplies the ones you will use constantly, such as the function type that takes a value and returns a value, the predicate that takes a value and returns a boolean, the supplier that produces a value, the consumer that accepts a value, and the runnable that takes nothing. In practice you rarely declare your own.

Define your own when the name carries domain meaning that the generic types do not. A function called CustomerValidator says something specific, and a reader of the code understands what it does without having to look at the parameter and return types. A generic function type used across a package often hides what is actually being computed.

Second, define your own when you need two or more parameters with distinct meanings and no sensible order. A pair of functions that are easy to swap by mistake is worse than one function with a named argument type.

Third, define your own when you want to document a contract more precisely than a type can, for example by adding default methods that express the rules, or by using a name that captures a precondition.

Against that, reuse the library types when the meaning really is generic. Reusing them keeps the number of concepts in a codebase small, which matters more than naming elegance when the function is used in only one or two places. The test is whether the name would help a reader who has never seen the code. If not, a standard type is better.

One practical note: if you do declare your own, annotate it so the compiler checks that it really has exactly one abstract method, and so that lambda parameter names show up in tooling.