Java Iterator vs Stream: Practical Usage and Code Examples

When you need to traverse a collection in Java, you have two primary choices: the Iterator interface, available since Java 1.2, and the Stream API, introduced in Java 8. The choice between these APIs affects how you write, read, and maintain your code. Each has distinct behavior around state, laziness, and reusability, and the right choice depends on what you are trying to accomplish.

The Core Difference: Pull-Based Cursor vs Declarative Pipeline

An Iterator is a pull-based cursor. You explicitly call hasNext() and next() to move through elements, and you control the loop yourself. This gives you direct access to the current element and, when the underlying collection supports it, allows you to remove the current element through the iterator's remove() method.

List<String> names = Arrays.asList("Alice", "Bob", "Charlie");
Iterator<String> it = names.iterator();
while (it.hasNext()) {
    String name = it.next();
    System.out.println(name);
}

A Stream, on the other hand, is a declarative pipeline. You describe what you want to do with the elements, and the stream engine handles the iteration internally. Streams are designed around functional operations like filter, map, and reduce, and they support both sequential and parallel execution.

List<String> names = Arrays.asList("Alice", "Bob", "Charlie");
names.stream()
     .map(String::toUpperCase)
     .forEach(System.out::println);

The iterator gives you fine-grained control over the traversal process, while the stream abstracts that process away in favor of composition and readability.

Reusability and State: One-Shot vs Recreatable

Both Iterator and Stream are single-use. Once you consume an iterator or a stream, you cannot reuse it. However, the way they handle state differs significantly.

An Iterator is a stateful object that remembers its current position. You can stop iterating and resume later, as long as you keep a reference to the iterator. This is useful when you need to interleave traversal with other logic or when you want to manually control the iteration pace.

A Stream is also stateful internally, but you cannot pause and resume it in the same way. Once you apply a terminal operation, the stream is consumed. To traverse again, you must create a new stream from the source. This is fine when the source is a collection or a generator, but it means streams are less suitable for scenarios where you need to hold a traversal position across method calls.

Lazy Evaluation and Short-Circuiting

One of the biggest advantages of streams is lazy evaluation. Intermediate operations like filter and map do not execute until a terminal operation is invoked. Moreover, streams can short-circuit: if you use findFirst() or limit(), the stream stops processing as soon as the result is found, potentially avoiding work on the entire collection.

List<Integer> numbers = IntStream.range(1, 1_000_000)
                                .boxed()
                                .collect(Collectors.toList());
Optional<Integer> firstEven = numbers.stream()
                                     .filter(n -> n % 2 == 0)
                                     .findFirst();

In this sequential stream, the pipeline does not process all one million numbers; it stops after finding the first even number. An Iterator requires you to write this short-circuiting logic manually, but it also gives you the flexibility to break out of the loop at any point, not just at specific terminal operations.

With an iterator, you can break based on any condition, even one that depends on external state or side effects. With a stream, short-circuiting is limited to built-in operations such as limit, findFirst, and anyMatch. If you need a custom short-circuit condition, an iterator or a loop may be clearer.

Performance and Memory Considerations

Performance is often cited as a reason to choose one over the other, but the reality is more nuanced. Streams introduce some overhead due to abstraction and the creation of intermediate objects, but this is usually negligible for typical collection sizes. The bigger performance concerns are boxing and memory allocation.

When numeric work is in a tight loop, prefer the primitive stream specializations. IntStream.range(0, 100).sum() avoids creating Integer objects, while a boxed Stream<Integer> can incur boxing costs. This can have a measurable impact in large or compute-heavy loops, so profile rather than assume.

Parallel streams can improve throughput on multi-core processors, but they come with their own costs. Parallelism introduces thread scheduling overhead, and the stream must be able to split the source efficiently. For small collections or operations that are not CPU-intensive, parallel streams can be slower than sequential ones. The decision to use parallel streams should be based on profiling, not intuition.

Iterators have simpler mechanics and can have lower per-element overhead. They also let you use remove() when the underlying collection supports it, which is not possible with streams. If you need to remove elements while traversing, an iterator is the direct approach.

Code Readability and Maintainability

Streams often produce more concise and readable code for common operations like filtering, mapping, and grouping. The declarative style makes the intent explicit, and the chain of operations reads like a description of the transformation.

Map<Department, List<Employee>> byDept = employees.stream()
    .filter(Employee::isActive)
    .collect(Collectors.groupingBy(Employee::getDepartment));

Writing the same logic with an iterator would require a loop, a conditional, and explicit map merging. That is more verbose and easier to get wrong.

However, streams are not always clearer. Complex branching, exception handling, or interactions with non-functional code can make a loop with an iterator more straightforward. For example, if you need to call a method that throws a checked exception inside the loop, streams force you to wrap it in a try-catch or use a helper method that sneaks the exception out. This often results in more boilerplate than a simple for loop with an iterator.

When to Choose Iterator Over Stream

Use an Iterator when you need to remove elements from the underlying collection during traversal and the iterator supports remove() (many collection iterators do, but not all). The Iterator.remove() method is designed for this and is safe to call once per next() invocation. Streams do not support structural modification of the source during processing.

Use an Iterator when you need to break out of the loop based on a condition that is not easily expressed as a stream short-circuit operation. For instance, if you need to stop after a certain number of elements that match a complex predicate involving external state, a manual loop gives you full control.

Use an Iterator when you are dealing with legacy code or when you need to implement an Iterable for a custom data structure. The Iterable interface is expected in many APIs, and returning an iterator is often simpler than building a custom stream source.

When to Choose Stream Over Iterator

Use a Stream when you need to transform, filter, aggregate, or group elements in a pipeline. Streams excel at composing multiple operations without intermediate collections, and they support parallel execution with a single call to parallel().

Use a Stream when you want to leverage built-in short-circuiting operations like findFirst, anyMatch, or limit. These operations make the short-circuit behavior explicit and are often more convenient than writing manual breaks, especially when the source is large.

Use a Stream when you are working with primitive numeric ranges or when you need to generate infinite sequences. IntStream.iterate and Stream.generate provide clean ways to create streams that are not easily replicated with iterators.

Handling Checked Exceptions in Streams

One of the most practical differences between iterators and streams is how they deal with checked exceptions. In a typical iterator loop, you can throw a checked exception directly from the loop body, and the method signature can declare it.

public void process(List<String> items) throws IOException {
    Iterator<String> it = items.iterator();
    while (it.hasNext()) {
        writeToFile(it.next()); // writeToFile throws IOException
    }
}

With streams, the lambda passed to forEach, map, or filter cannot throw a checked exception. The functional interfaces like Consumer and Function do not declare checked exceptions. You have two options: wrap the exception in a runtime exception, or create a helper method that sneaks the checked exception out.

public void process(List<String> items) {
    items.stream().forEach(item -> {
        try {
            writeToFile(item);
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }
    });
}

This adds boilerplate and turns a checked exception into an unchecked one. If you need the calling code to handle the original checked exception directly, an iterator or a traditional for-each loop is often cleaner. This is a concrete tradeoff that should influence your choice, especially in code that performs I/O or other operations with checked exceptions.