How do Stream.iterate and Stream.generate create infinite streams, and how do you make such a pipeline terminate?

## The problem: a stream with no end Most stream sources (a list, an array) are **finite** — they run out. But sometimes you want a *generated* sequence: the natural numbers, repeated random values, a constant repeated. Java offers two **infinite** stream factories. Because they never end on their own, the key skill is making the pipeline **terminate**. ## Stream.iterate (two-arg form) ```java Stream.iterate(1, n -> n * 2) // 1, 2, 4, 8, 16, ... ``` `Stream.iterate(seed, f)` takes a starting value `seed` and a **UnaryOperator** `f` (a function `T -> T`). It emits `seed`, then `f(seed)`, then `f(f(seed))`, and so on — **each element depends on the previous one**, so the stream is *ordered* and inherently sequential. This is ideal for sequences like powers of two, Fibonacci (with a pair as the seed), or stepping a date forward. ## Stream.generate ```java Stream.generate(() -> "x") // "x", "x", "x", ... Stream.generate(Math::random) // fresh random each call ``` `Stream.generate(supplier)` takes a **Supplier** (`() -> T`) and calls it *every time* it needs the next element. There is **no dependency on the previous value** — each element is produced independently — so it's perfect for constants, random values, or pulling from an external source. Being order-independent, it parallelizes well. ## Why they never finish, and laziness saves you A terminal operation on an infinite stream tries to consume *all* elements — which never ends. Example of an infinite hang: ```java Stream.iterate(0, n -> n + 1).forEach(System.out::println); // runs forever ``` The escape is a **short-circuiting** operation, which streams evaluate **lazily** — elements are produced only as pulled, so the source is asked for exactly as many as needed: - `limit(n)` — take the first `n`, then stop. - `takeWhile(predicate)` — emit while the predicate holds; stop at the first element that fails (Java 9+). - `findFirst()`, `findAny()`, `anyMatch()`, `allMatch()`, `noneMatch()` — short-circuit as soon as the answer is known. ```java Stream.iterate(1, n -> n * 2).limit(5).toList(); // [1, 2, 4, 8, 16] Stream.generate(Math::random).limit(3).toList(); // three randoms ``` ## The Java 9 three-arg iterate (self-bounding) Java 9 added an overload that bakes the stop condition into the source — a functional `for` loop: ```java Stream.iterate(1, n -> n <= 16, n -> n * 2) // 1, 2, 4, 8, 16 — stops itself ``` The middle argument is a **Predicate** (`hasNext`): emission continues while it returns true. This is *bounded by construction*, so no `limit` is needed. It mirrors `for (int n = 1; n <= 16; n *= 2)`. ## Important gotchas - `limit` placement matters with `iterate`: `iterate(...).filter(...).limit(n)` can *hang* if fewer than `n` elements ever pass the filter — `limit` waits for `n` survivors that never arrive. `takeWhile` is safer when the stop condition is on the value. - Don't make a `generate` supplier stateful and then run it in parallel — shared mutable state across threads causes races. - `iterate`'s sequential dependency makes parallel execution mostly unhelpful; `generate`/unordered sources parallelize better. ## Mental model Think of `iterate`/`generate` as taps that *never close*. The short-circuit (or three-arg form) is the valve that decides how much water you draw — and laziness guarantees you only draw exactly that much.