filter, map and flatMap

For this lesson, we'll focus on the practical stream operations interviewers expect you to use fluently: filter with lambdas and method references, map as a one-to-one transform, flatMap for nested lists and order lines, Optional::stream, mapMulti since Java 16, and the right way to express small if/else decisions inside a pipeline. Interviewers ask this because weak answers often know the method names but cannot explain the shape change.

01Picture it first: keep, relabel, then flatten boxes

Picture a warehouse belt. The first worker removes unpaid orders, the second worker prints one shipping label for each remaining order, and the third worker opens each order box and sends every line item forward. That third worker is the shape change people miss: one box can produce three line items, and an empty box can produce none.

Ask what shape comes out. If the answer is one output per input, reach for map. If the answer is zero or more outputs per input, reach for flatMap or sometimes mapMulti.

Fig. 1

A stream of three orders goes through map to produce three labels, while flatMap opens each order into a single stream of line items with zero, one or many outputs per order

02filter under the hood: a gate with a predicate

filter is the easiest operation to read and one of the easiest to abuse. A predicate should answer one yes/no question. When that question already has a domain name, I prefer the method reference because it reads like a sentence.

import java.util.List;

record Order(String id, int cents, boolean paid) {
    boolean isLargePaidOrder() {
        return paid && cents >= 1_000;
    }
}

final class FilterDemo {
    public static void main(String[] args) {
        List<Order> orders = List.of(
                new Order("o-1", 1200, true),
                new Order("o-2", 700, true),
                new Order("o-3", 4000, false)
        );

        List<String> withLambda = orders.stream()
                .filter(order -> order.paid() && order.cents() >= 1_000)
                .map(Order::id)
                .toList();

        List<String> withMethodReference = orders.stream()
                .filter(Order::isLargePaidOrder)
                .map(Order::id)
                .toList();

        System.out.println(withLambda);
        System.out.println(withMethodReference);
    }
}

The output is:

[o-1]
[o-1]

Notice three things.

• The lambda is fine when the rule is short and local.
• The method reference is better once the rule has business meaning and a name.
• filter does not change the element type. We still have Order until map(Order::id).

Two filters can also be clearer than one dense predicate when each rule deserves a name.

List<String> ids = orders.stream()
        .filter(Order::paid)
        .filter(order -> order.cents() >= 1_000)
        .map(Order::id)
        .toList();

This is not slower in the way people fear for normal service code. Stateless operations are fused during traversal, which we cover in How a stream pipeline executes. For 500 orders, readability beats trying to save one predicate call.

03map: one input becomes one output

map is a transformation. The count of elements is the same as the count coming in, unless an earlier operation already removed some. The type can change, but the cardinality does not.

import java.util.List;

record Order(String id, int cents, boolean paid) { }
record Receipt(String orderId, String displayTotal) { }

final class MapDemo {
    public static void main(String[] args) {
        List<Order> orders = List.of(
                new Order("o-1", 1200, true),
                new Order("o-2", 700, false),
                new Order("o-3", 2500, true)
        );

        List<Receipt> receipts = orders.stream()
                .filter(Order::paid)
                .map(order -> new Receipt(order.id(), "$" + order.cents() / 100))
                .toList();

        System.out.println(receipts);
    }
}

The output is:

[Receipt[orderId=o-1, displayTotal=$12], Receipt[orderId=o-3, displayTotal=$25]]