Functional programming in Java

When an interviewer asks "what is functional programming?", they rarely want a lecture on lambda calculus. They want to know whether you understand why the style helps (code that's easier to test, reason about and parallelise), whether you can name its building blocks, and, most of all, whether you know where it breaks down in Java: side effects inside streams, recursion without tail calls, and streams that are slower than the loop they replaced.

For this lesson, we'll focus on the core ideas (pure functions, immutability, higher-order functions, referential transparency), composition and currying, laziness, recursion, side-effect pitfalls in streams, the imperative versus declarative trade-off, and an honest performance comparison.

01Picture it first: a calculator versus a chef in your kitchen

A pure function is like a calculator. Press 1000 × 0.9 and you get 900, today, tomorrow, on anyone's calculator, and the calculator doesn't rearrange your desk while doing it. An impure function is like a chef you invite into your kitchen: you ask for an omelette, and you get one, but the result depends on what's in your fridge right now, and afterwards your eggs are gone and the pans have moved.

Neither is wrong; programs need side effects eventually, or they'd do nothing. The functional idea is to keep the calculator part as large as possible and push the kitchen part (database writes, clocks, network calls) to the edges, where you can see it.

Here's the difference for a pricing function; watch the hidden arrows on the right.

Fig. 1

Two panels: a pure finalPrice takes cents and a date and returns 900, with nothing else touched; an impure finalPrice takes an order but also secretly reads the system clock, increments a counter field and writes a log line, so the same input can give different outputs

02Functional ideas under the hood

Pure functions and referential transparency

// Impure: depends on the clock and changes shared state
class DiscountService {
    private int discountsGiven = 0;

    long finalPrice(Order order) {
        boolean friday = LocalDate.now().getDayOfWeek() == DayOfWeek.FRIDAY;
        if (friday) discountsGiven++;
        return friday ? order.cents() * 90 / 100 : order.cents();
    }
}

// Pure: everything it depends on arrives as a parameter
static long finalPrice(long cents, LocalDate today) {
    return today.getDayOfWeek() == DayOfWeek.FRIDAY ? cents * 90 / 100 : cents;
}

finalPrice(1_000, LocalDate.of(2026, 10, 16));   // a Friday: prints 900

For the impure version you need to fake the system clock or wait until Friday, and the counter means two calls in a row don't leave the object in the same state. The pure version takes a date, so the test is one line.

Notice three things:

• A pure function has two properties: the same inputs always give the same output, and calling it has no observable effect (no field writes, no I/O, no exceptions thrown on valid input).
• Referential transparency follows from purity: finalPrice(1_000, friday) can be replaced by 900 anywhere in the program without changing behaviour. That's what makes caching (memoisation) and reordering safe.
• You don't need a framework to get this. Passing LocalDate or a java.time.Clock in, instead of reading LocalDate.now() inside, is the whole trick.

Immutability

Pure functions are much easier to keep pure when the data they receive can't change under them. Java gives you three tools: final fields, records (shallowly immutable by design), and unmodifiable collections like List.of and List.copyOf.

record Cart(String userId, List<LineItem> items) {
    Cart {
        items = List.copyOf(items);              // defensive, unmodifiable copy
    }

    Cart add(LineItem item) {                    // "change" = return a new Cart
        var next = new ArrayList<>(items);
        next.add(item);
        return new Cart(userId, next);
    }

    long totalCents() {
        return items.stream().mapToLong(LineItem::cents).sum();
    }
}

cart.add(item) leaves cart untouched and returns a new one, so any thread holding the old cart sees a consistent snapshot without locks. The cost is a copy per change, which is fine for a 20-line cart and wrong for a 2-million-entry index; persistent collections (Vavr, PCollections) share structure to make that cheaper, but the JDK doesn't ship them.

Watch the difference between unmodifiable and immutable. Collections.unmodifiableList(list) is a read-only view: if someone still holds list, they can change it and your "immutable" view changes too. List.copyOf takes a real copy. And a record holding a List<LineItem> is only as immutable as LineItem.

First-class and higher-order functions