Streams vs Collections: What Changes?

A collection stores elements. A stream computes them. That single difference explains everything else: the interfaces, the laziness, the single use, and the fact that a stream is a description of work rather than a container of results.

A collection has a size you can ask for at any time, supports random access where the implementation allows it, and can be iterated as many times as you like because the data is already there. A stream has none of those things. It has no size, no get method, and it can only be traversed once, because the traversal is the computation.

import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;

public class Main {
    public static void main(String[] args) {
        List<String> names = List.of("Ada", "Grace", "Alan", "Katherine");

        // The imperative version.
        List<String> imperative = new ArrayList<>();
        for (String name : names) {
            if (name.length() > 3) {
                imperative.add(name.toUpperCase());
            }
        }
        System.out.println("imperative : " + imperative);

        // The stream version.
        List<String> functional = names.stream()
                .filter(n -> n.length() > 3)
                .map(String::toUpperCase)
                .collect(Collectors.collect(java.util.stream.Collectors.toList()));
        System.out.println("stream     : " + functional);

        // A stream does not change the source.
        System.out.println("source     : " + names);
    }
}

The output shows both versions producing the same result, and the source list unchanged in both cases. The difference is in how you read the code: the imperative version tells you the order of the steps and leaves you to work out what it is computing, while the stream version names each step.

One performance point that is often misstated. Streams are not automatically faster than loops. They are usually about the same for a simple in-memory transformation, and the stream version allocates a little more because of the pipeline objects and, if you collect, the result collection. The win is not speed — it is that a pipeline can short-circuit, can be parallelised with a single call, and reads as a description of intent.

Because a stream pipeline is a description of a computation, not the computation itself. Nothing is executed until a terminal operation is called — forEach, collect, count, anyMatch, reduce. Until then the pipeline is just a chain of objects describing what would happen if you asked for a result. This is what makes short-circuiting possible: anyMatch can stop pulling elements the moment it finds a match, because it never had to materialise them all.

Reusing a stream after it has been consumed throws IllegalStateException. The message is explicit — the stream has already been operated upon or closed — and the reason is that the traversal is the computation. The pipeline holds one-shot state, so a second traversal has nothing to continue from.

import java.util.stream.Stream;

public class Main {
    public static void main(String[] args) {
        Stream<String> stream = Stream.of("a", "b", "c");

        // Nothing has happened yet - the pipeline is only a description.
        System.out.println("created but not consumed");

        stream.forEach(s -> System.out.println("consumed: " + s));

        // A stream can only be used once.
        try {
            stream.forEach(s -> System.out.println("again: " + s));
        } catch (IllegalStateException e) {
            System.out.println("second use -> IllegalStateException");
        }
    }
}

The output shows the sequence. The message about creating the stream prints with nothing consumed yet. The first forEach pulls all three elements through the pipeline. The second forEach throws immediately, because the pipeline is spent.

The practical guidance is to keep the stream in one expression and call a terminal operation at the end of it. If you need the result twice, materialise it with toList and work with the list, or call stream() on the source again to get a fresh pipeline. And because laziness means the source is read when the terminal operation runs, a stream over a mutable collection reflects the collection's state at that moment, not at the moment you created the stream.