Functional Interface Specializations in Java

This loop looks harmless, but over ten million iterations it allocates ten million objects nobody asked for:

Function<Integer, Integer> square = x -> x * x;

long sum = 0;
for (int i = 0; i < 10_000_000; i++) {
    sum += square.apply(i);   // int -> Integer -> int on every step
}

The abstract method of Function is declared as R apply(T t), and generics only work with objects. So every int is boxed into an Integer and immediately unboxed again. Swap the variable type for IntUnaryOperator, whose method is int applyAsInt(int), and the boxing disappears completely. That is exactly why the JDK ships specialized versions of its functional interfaces.

Functional interface specializations are variants of the core interfaces in the java.util.function package that are built for a different number of arguments (binary specializations) or for the primitive types int, long and double instead of objects (primitive specializations). In total, java.util.function contains 43 interfaces: 9 generic (object-based) and 34 primitive ones.

The core functional interfaces

Everything in java.util.function grows out of five generic interfaces. Each one has a single abstract method, so each can be the target type of a lambda expression or a method reference.

The remaining 38 interfaces in the package are variations on these five, plus BiFunction and BinaryOperator. Once you know the naming rule, you can reconstruct any of them from its name alone.

Why specializations exist: the cost of autoboxing

Java generics cannot be parameterized with primitives: Function<int, int> simply does not compile. That forces every generic functional interface to accept and return objects. When you hand a number to one of them, autoboxing kicks in on the way down and unboxing on the way back.

What that costs in practice:

• every boxed int is a separate heap object - roughly 16 bytes plus a 4 to 8 byte reference on 64-bit HotSpot, against 4 bytes for the primitive;
• millions of short-lived Integer objects put pressure on the garbage collector;
• an array of Integer references is scattered across the heap, while an int[] is one contiguous block - you lose data locality and CPU cache efficiency.

Primitive specializations solve this at the signature level: their abstract methods are declared over primitives directly.

// Boxes on every single call
Function<Integer, Integer> squareBoxed = x -> x * x;

// Zero boxing: int in, int out
IntUnaryOperator square = x -> x * x;

int sum = IntStream.rangeClosed(1, 100)
                   .map(square)   // IntUnaryOperator
                   .sum();        // 338350

Binary specializations

Predicate<T>, Consumer<T> and Function<T, R> all take a single argument. For two arguments, java.util.function provides binary specializations carrying the Bi- prefix. The two-argument counterpart of UnaryOperator is not called BiUnaryOperator — it is BinaryOperator<T>, which extends BiFunction<T, T, T>. There is no binary version of Supplier, because a supplier takes no arguments at all.

BiFunction<String, Integer, String> repeat = (s, n) -> s.repeat(n);
System.out.println(repeat.apply("ab", 3));        // ababab

BiPredicate<String, Integer> isLonger = (s, n) -> s.length() > n;
System.out.println(isLonger.test("Java", 3));     // true

BiConsumer<String, Integer> printer = (k, v) -> System.out.println(k + " = " + v);
printer.accept("age", 30);                        // age = 30

BinaryOperator<Integer> max = BinaryOperator.maxBy(Comparator.naturalOrder());
System.out.println(max.apply(7, 42));             // 42

String.repeat() is available from Java 11 onwards. Note that the JDK stops at two arguments: there is no TriFunction or anything with three or more parameters in the standard library, so you declare your own when you need one.

Primitive specializations: the full list

Primitive specializations exist for three types — int, long and double — plus BooleanSupplier for boolean. Here is the complete set, grouped by the generic interface each group derives from.

Predicate specializations

Just like Predicate<T>, these three have the default methods and(), or() and negate() for combining conditions.

Consumer specializations

@FunctionalInterface
public interface IntConsumer {
    void accept(int value);
    // plus the default method andThen(IntConsumer)
}

IntConsumer ic = i -> System.out.println(i * 2);
ic.accept(8);   // 16 - no Integer is ever created
ic.accept(9);   // 18

Function specializations

With Function<T, R> the primitive can sit on the input side, the output side, or both — hence three subgroups.

Primitive in, object out

Object in, primitive out

Primitive in, primitive out

There is deliberately no IntToIntFunction or DoubleToDoubleFunction — IntUnaryOperator and DoubleUnaryOperator already fill that slot.

Supplier specializations

Notice the method names: Supplier<T> declares get(), while the primitive versions declare getAsInt(), getAsLong(), getAsDouble() and getAsBoolean(). The names differ on purpose — after type erasure, four methods called get() with different return types could not coexist.

UnaryOperator specializations

BinaryOperator specializations

BiConsumer specializations

The argument order is fixed: the object comes first, the primitive second. That shape is what the three-argument IntStream.collect() expects for its accumulator.

ObjIntConsumer<StringBuilder> append = StringBuilder::append;

StringBuilder sb = new StringBuilder("x=");
append.accept(sb, 42);
System.out.println(sb);   // x=42

BiFunction specializations

There is no IntBiFunction and no primitive BiPredicate: two primitive arguments are covered only by IntBinaryOperator and its long and double siblings.

How to decode an interface name

Names in java.util.function follow a strict pattern. Learn it once and you can reconstruct the signature of any of the 43 interfaces from its name, without opening the Javadoc.

Method names follow the same logic: when the result is a primitive, the verb gets an As plus type suffix — applyAsInt, applyAsLong, applyAsDouble, getAsInt, getAsBoolean. test and accept need no suffix, because their return types (boolean and void) are fixed anyway.

Where these interfaces show up in the Stream API

In everyday code you rarely declare a variable of type ToIntFunction. You meet these interfaces in the signatures of Stream, IntStream, Map and List methods, where they decide which lambda shape the compiler expects from you.

List<String> words = List.of("Java", "Stream", "API");

// ToIntFunction<String>: object -> primitive
int totalLength = words.stream()
                       .mapToInt(String::length)
                       .sum();                       // 13

// IntPredicate: filtering without boxing
long evenCount = IntStream.rangeClosed(1, 10)
                          .filter(n -> n % 2 == 0)
                          .count();                  // 5

// IntBinaryOperator: reduction
int factorial = IntStream.rangeClosed(1, 5)
                         .reduce(1, (a, b) -> a * b); // 120

// IntFunction<String>: primitive -> object
List<String> labels = IntStream.rangeClosed(1, 3)
                               .mapToObj(n -> "#" + n)
                               .toList();             // [#1, #2, #3]

Where developers get tripped up

• Primitive interfaces do not extend the generic ones. IntBinaryOperator is not a subtype of BiFunction, and IntPredicate is not a subtype of Predicate. They are independent types, so a variable of one cannot be assigned to a variable of the other.
• IntFunction, ToIntFunction and ToIntBiFunction have no default methods. The familiar andThen() and compose() live on Function, IntUnaryOperator and DoubleUnaryOperator, but not on the mixed specializations — you chain those by hand inside a lambda.
• There are no specializations for float, byte, short or char. You use the int and double versions and rely on widening conversion.
• UnaryOperator<T> and Function<T, T> are interchangeable in one direction only. A UnaryOperator<String> can be passed where a Function<String, String> is expected, but not the other way around: UnaryOperator extends Function, it does not equal it.
• Forgetting boxed(). To turn an IntStream into a Stream<Integer> and collect it into a List<Integer>, you need boxed() or mapToObj() first.