Intermediate vs terminal operations

For this lesson, we'll focus on the line you need to draw in interviews: which operations build the pipeline, which operations execute it, why a stream without a terminal operation does nothing, and why a stream is single-use once it has been linked or consumed. Interviewers ask this because it is the quickest way to tell whether you learned streams as syntax or as a lazy execution model.

01Picture it first: writing the ticket, then pulling the line

Picture a cafe ticket printer. Each intermediate operation adds one instruction to the ticket: keep paid orders, turn them into cents, sort them by amount. Nothing is made yet, because the ticket has not reached the barista.

The terminal operation is the barista pulling the next order through the line. No terminal operation means no traversal. That one sentence prevents half the beginner stream bugs I see in code review.

Fig. 1

A stream source has intermediate stages that only add instructions until a terminal operation pulls elements through the pipeline

Notice the direction. The source sits on the left, the intermediate stages sit in the middle, and the terminal operation is the thing that asks for elements. We cover the Sink chain behind that pull in How a stream pipeline executes; here we care about the public API boundary.

02Laziness under the hood: a pipeline without a terminal does nothing

import java.util.List;
import java.util.stream.Stream;

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

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

        Stream<Integer> paidCents = orders.stream()
                .peek(order -> System.out.println("peek " + order.id()))
                .filter(Order::paid)
                .map(Order::cents);

        System.out.println("pipeline built");
        System.out.println(paidCents.count());
    }
}

On Java 21, the output is:

pipeline built
peek o-1
peek o-2
peek o-3
2

peek, filter and map did not run when paidCents was assigned. They ran when count() started consuming the pipeline. If you remove the terminal operation, the program prints only pipeline built.

Notice three things:

• filter and map return stream objects, so they can be chained.
• count() returns a long, so the pipeline is over after it runs.
• peek is not a reliable business side-effect hook. It only runs if traversal happens, and some terminals can skip traversal when the size is already known.

Here is the trade-off I recommend. Use streams when your code reads like a transformation from source to result. Use a loop when the important part is mutation, early break with complex rules, checked exceptions, or logging that must happen exactly once per element.

03The intermediate operation catalogue

Intermediate operations answer the question, "What should happen to each element before the final answer is produced?" Some are stateless, meaning they do not need to remember other elements. Some are stateful, meaning they may need memory, coordination, buffering, or knowledge of encounter order.

The table is dense, but the mental split is small. Stateless operations can usually stream element by element. Stateful operations may need to remember what came before or wait for more input before sending anything downstream.

import java.util.List;

final class StatefulIntermediateDemo {
    public static void main(String[] args) {
        List.of("paid", "failed", "created", "refunded").stream()
                .peek(status -> System.out.println("source " + status))
                .sorted()
                .limit(2)
                .forEach(status -> System.out.println("out " + status));
    }
}

The output is:

source paid
source failed
source created
source refunded
out created
out failed

sorted() is the barrier. It must see the finite input before it knows the first sorted value, so limit(2) cannot save it from reading all four elements. This is why stream.sorted().findFirst() is often the wrong way to get a minimum; use min(comparator) when you only need one best element.

04The terminal operation catalogue

Terminal operations answer the question, "What final result do we want?" They trigger traversal, produce the answer, and consume the stream. After one terminal operation, you should treat the stream object as dead.

iterator() and spliterator() surprise people because they do not look like count() or toList(). They still consume the pipeline contract: once you ask a stream for its traversal cursor, do not keep using the original stream. The cursor becomes the way you consume it.

05Advanced: why reuse throws "operated upon or closed"

Streams are deliberately one-shot. In OpenJDK's AbstractPipeline, the source stage has a boolean named linkedOrConsumed. When you attach another intermediate stage, the previous stage is marked as linked. When a terminal operation evaluates the pipeline, the source stage is marked as consumed.

That guard catches two families of mistakes. First, you cannot use the same stream for two terminal operations. Second, you should not keep using an earlier stream reference after you have already linked a child pipeline from it.

Fig. 2

A stream source flips its linkedOrConsumed guard when a child stage is linked and again when a terminal operation consumes the pipeline

import java.util.List;
import java.util.stream.Stream;

final class StreamReuseDemo {
    public static void main(String[] args) {
        Stream<String> statuses = List.of("paid", "failed", "paid").stream();
        Stream<String> paid = statuses.filter("paid"::equals);

        try {
            statuses.count();
        } catch (IllegalStateException e) {
            System.out.println(e.getMessage());
        }

        System.out.println(paid.count());

        try {
            paid.findFirst();
        } catch (IllegalStateException e) {
            System.out.println(e.getMessage());
        }
    }
}

On Java 21, both caught messages are:

stream has already been operated upon or closed
stream has already been operated upon or closed

The first exception happens because statuses.filter(...) already linked a new stage to statuses. The second happens because paid.count() consumed the pipeline. The JDK does not try to rewind the source, because many sources cannot be rewound: a socket, a file reader, a generator, or a spliterator over a mutable data structure.

Common causes are boring and common:

Here is the supplier pattern. It is useful when the source is reusable and you want to describe the same pipeline twice.

import java.util.List;
import java.util.function.Supplier;
import java.util.stream.Stream;

final class StreamSupplierFixDemo {
    public static void main(String[] args) {
        List<String> statuses = List.of("paid", "failed", "paid");
        Supplier<Stream<String>> paidStatuses = () -> statuses.stream()
                .filter("paid"::equals);

        System.out.println(paidStatuses.get().count());
        System.out.println(paidStatuses.get().toList());
    }
}

For a small result that you truly need more than once, collect and re-stream the collection. The simple option is Supplier<Stream<T>>; it stops being enough when the source is expensive, remote, or time-sensitive. In that case, materialize deliberately and name the cost.

import java.util.List;

record Invoice(String id, int cents, boolean overdue) { }

final class CollectThenRestreamDemo {
    public static void main(String[] args) {
        List<Invoice> overdue = List.of(
                new Invoice("i-1", 500, true),
                new Invoice("i-2", 700, false),
                new Invoice("i-3", 300, true)
        ).stream()
                .filter(Invoice::overdue)
                .toList();

        int total = overdue.stream().mapToInt(Invoice::cents).sum();
        List<String> ids = overdue.stream().map(Invoice::id).toList();

        System.out.println(total);
        System.out.println(ids);
    }
}

06Closing streams: onClose, close() and Files.lines

Most collection streams do not hold operating-system resources, so you normally do not close orders.stream(). But every stream implements BaseStream, which extends AutoCloseable. Closing a stream runs any registered onClose handlers, and after close, later use throws the same operated-upon-or-closed exception.

import java.util.List;
import java.util.stream.Stream;

final class OnCloseDemo {
    public static void main(String[] args) {
        Stream<String> stream = List.of("paid", "failed").stream()
                .onClose(() -> System.out.println("closed"));

        System.out.println(stream.count());
        stream.close();
    }
}

The output is:

2
closed

count() consumes the stream, but it does not automatically call close(). If you registered close handlers or opened a resource-backed stream, you own the close. Closing twice is allowed; close handlers run at most once for that stream chain.

Files.lines(path) is the important everyday case. It opens a file-backed stream and the JDK documentation says it should be used in a try-with-resources statement. That is the default I want you to use in services and coding interviews.

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.stream.Stream;

final class FilesLinesCloseDemo {
    public static void main(String[] args) throws IOException {
        Path path = Path.of("orders-stream-demo.txt");
        Files.writeString(path, "paid\nfailed\npaid\n");

        try (Stream<String> lines = Files.lines(path)) {
            long paid = lines.filter("paid"::equals).count();
            System.out.println(paid);
        }

        Files.deleteIfExists(path);
    }
}

07How to say it in the interview

When I ask this question, I'm listening for three things: laziness, the return type split, and the one-shot rule. If you also mention stateful operations and Files.lines, I know you have written streams outside toy examples.