Infinite streams with iterate and generate

For this lesson, we'll focus on building unbounded and bounded sequences with Stream.iterate, the Java 9 three-argument iterate, Stream.generate, primitive infinite streams and Random.ints(). We'll also cover how to make these streams finite, where ordered and unordered behavior matters, and why some innocent-looking operations never return. For slicing mechanics, see Slicing streams: skip, limit, takeWhile and dropWhile; for short-circuiting terminals, see findFirst vs findAny and short-circuiting.

01Picture it first: conveyor belt versus ticket machine

Picture two machines. iterate is a conveyor belt where each box is built from the previous box: 1, 2, 4, 8. generate is a ticket machine: each pull asks the supplier for another ticket, and the stream API does not promise a meaningful order between pulls.

That difference is the whole lesson. Use iterate when the next value depends on the last value; use generate when each value can be produced independently. Then add a stop condition close enough that the reader can see it.

Fig. 1

Stream iterate builds each value from the previous value while generate asks an independent supplier for the next value

02iterate under the hood: a previous value plus a next function

Stream.iterate(seed, next) starts with the seed, emits it, then stores the result of next(seed) as the next value. It is ordered because there is a clear predecessor for every value after the seed. That makes it a natural fit for counters, schedules, IDs and recurrence-style sequences.

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

final class BackoffScheduleDemo {
    public static void main(String[] args) {
        List<Integer> delaysMs = Stream.iterate(100, delay -> delay * 2)
                .limit(5)
                .toList();

        System.out.println(delaysMs);
    }
}

The output is:

[100, 200, 400, 800, 1600]

Notice three things.

• The seed, 100, is emitted as the first element.
• limit(5) is not decoration. It is the reason toList() can finish.
• The sequence is ordered, so skip, limit, takeWhile and findFirst have prefix semantics.

Here is how I'd write a slightly more realistic retry schedule. A retry loop might cap delay at 5 seconds and stop after 6 attempts because beyond that you are usually hiding an incident, not improving reliability.

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

record RetryDelay(int attempt, int millis) { }

final class RetryBackoffDemo {
    public static void main(String[] args) {
        List<RetryDelay> plan = Stream.iterate(
                        new RetryDelay(1, 100),
                        retry -> new RetryDelay(retry.attempt() + 1, Math.min(retry.millis() * 2, 5_000)))
                .limit(6)
                .toList();

        System.out.println(plan);
    }
}

The first version is a teaching example. This one is closer to production because it names the attempt and caps the delay. In real retry code, you would also add jitter so 1,000 clients do not retry at exactly the same millisecond.