Lambda Expression with Primitive Types in Java: Performance Impact?
Generic functional interfaces quietly box every primitive. Usually that's fine — until you're doing it a million times.
When you write a lambda in Java, it doesn't float free — it's an implementation of a functional interface, an interface with a single abstract method. Function, Predicate, Consumer, and Supplier are the everyday ones: transform a value, test it, consume it, produce it. You pass a lambda, Java treats it as an instance of the matching interface. So far, so clean.
The catch generics can't see
Here's the problem this whole post is about. Those interfaces are generic — Function<Integer, Integer>, Predicate. And Java generics don't work with primitives; they only hold objects. So the moment you use a lambda over int through a generic functional interface, every int has to be wrapped in an Integer object on the way in, and unwrapped on the way out. That wrapping is autoboxing, and it isn't free: each boxed value is a small object allocation. In a tight loop over millions of numbers, that's millions of throwaway objects created and collected — pure pressure on the garbage collector, doing nothing useful.
The fix: primitive functional interfaces
This is why the java.util.function package doesn't stop at four interfaces. It carries primitive specialisations: IntPredicate, IntFunction, IntConsumer, IntUnaryOperator, and the same family for long and double. They're the same shapes, written to take and return the primitive directly — an IntPredicate tests an int, not an Integer. Use them and the boxing simply doesn't happen; the int stays an int the whole way through. The interfaces look redundant until you realise they exist for exactly one reason: keeping primitives out of object wrappers on the hot path.
Does it actually matter?
Most of the time, no — and it's worth saying so plainly. For ordinary code handling a handful of values, the boxing cost is invisible, and reaching for IntPredicate over Predicate is premature optimisation that makes the code no clearer. Where it matters is volume: streams and loops processing large numeric datasets, where the same boxing repeats per element and the allocations pile up. That's exactly why the primitive stream types — IntStream, LongStream, DoubleStream — exist alongside the generic Stream. They carry primitives end to end, so a numeric pipeline never boxes.
The takeaway
The rule is simple, and it's really a rule about knowing your context. Default to the ordinary generic interfaces — they read fine and the cost is nothing at small scale. When you're processing large volumes of numbers and the profiler shows allocation pressure, switch to the primitive variants and the primitive streams, and the boxing disappears. It's a small, specific tool for a small, specific problem: don't wrap millions of numbers in objects just to hand them to a lambda. Reach for it when the numbers are large, ignore it when they're not, and don't let the existence of twenty near-identical interfaces convince you the everyday four aren't enough for everyday work.
