Hi Viktor,
Thanks for the explanation!
I also experimented with adding parallel() in the
middle, and it indeed threw a NullPointerException even
without distinct().
In our codebase, I see some developers using iterate()
+ takeWhile() and others using generate() +
takeWhile(). I am debating whether to raise a concern
about this pattern. Most likely, people won't insert
intermediary operations between them, and I worry I
might be overthinking it.
However,
generate(supplierThatMayReturnNull).takeWhile() seems
even more precarious. Since generate() is documented as
unordered, could it potentially return elements out of
encounter order, such as swapping a later null with an
earlier non-null return?
This brings me back to the rationale I’ve used to
discourage side effects in map() and filter(). In a
sequential stream, I’ve argued that relying on side
effects from an earlier map() to be visible in a
subsequent map() is unsafe because the stream is
theoretically free to process multiple elements through
the first map() before starting the second.
Is that view too pedantic? If we can safely assume
iterate() + takeWhile() is stable in non-parallel
streams, should the same logic apply to subsequent
map() calls with side effects (style issues aside)?
I’m trying to find a consistent theory. Should I advise
my colleagues that iterate() + takeWhile() and
generate() + takeWhile() are unsafe, or should I
reconsider my warnings about side effects being
rearranged in sequential streams?
I hope that clarifies the root of my confusion.
Best,
Jige Yu
On Mon, Mar 2, 2026 at 6:08 AM Viktor Klang
<[email protected]> wrote:
Hi Jige,
I think I understand what you mean. In this case
you're trying to prevent a `null`-return from
`nextOrNull()` to be fed into the next iteration
and thus throwing a NullPointerException.
Now the answer is going to be a bit nuanced than
you might want to hear, but in the spirit of
providing clarity, the code which you provided will
"work" under the assumption that there is no
"buffer" in between iterate(…) and takeWhile(…).
TL;DR: use Stream.iterate(seed, e -> e != null, e
-> e.nextOrNull())
Long version:
Imagine we have the following:
```java
recordE(Ee) {}
Stream.iterate(newE(newE(newE(null))), e ->e.e())
.< /span>takeWhile(Objects::nonNull)
.forEach(IO::println)
```
We get:
```java
E[e=E[e=E[e=null]]]
E[e=E[e=null]]
E[e=null]
```
However, if we do:
```java
Stream.iterate(newE(newE(newE(null))), e ->e.e())<
/span>
.gather(
Gatherer.<E,ArrayList<E>,E>ofSequential(
ArrayList::new,
(l, e, _) ->l.add(e),
(l, d) ->l.forEach(d::push)
)
)
.takeWhile(Objects::nonNull)
.forEach(IO::println)
```
We get:
```java
Exceptionjava.lang.NullPointerException:Cannotinvoke
"REPL.$JShell$16$E.e()"because "<parameter1>"is null
at lambda$do_it$$0(#5:1)
at Stream$1.tryAdvance(Stream.java:1515)
at
ReferencePipeline.forEachWithCancel(ReferencePipeline.java:147)
at
AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:588)
at AbstractPipeline.copyInto(AbstractPipeline.java:574)
at
AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
at
ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:153)
at
ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:176)
at AbstractPipeline.evaluate(AbstractPipeline.java:265)
at
ReferencePipeline.forEach(ReferencePipeline.java:632)
at(#5:9)
```
But if we introduce something like `distinct()`in
between, it will "work" under sequential processing,
but under parallel processing it might not, as the
distinct operation will have to buffer
*separately*from takeWhile:
```java
Stream.iterate(newE(newE(newE(null))), e ->e.e())<
/span>
.distinct()
.takeWhile(Objects::nonNull)
.forEach(IO::println)
```
```java
E[e=E[e=E[e=null]]]
E[e=E[e=null]]
E[e=null]
```
Parallel:
```java
Stream.iterate(newE(newE(newE(null))), e ->e.e())<
/span>
.parallel()
.distinct()
.takeWhile(Objects::nonNull)
.forEach(IO::println)
```
```java
Exceptionjava.lang.NullPointerException:Cannotinvoke
"REPL.$JShell$16$E.e()"because "<parameter1>"is null
at lambda$do_it$$0(#7:1)
at Stream$1.tryAdvance(Stream.java:1515)
at
Spliterators$AbstractSpliterator.trySplit(Spliterators.java:1447)
at AbstractTask.compute(AbstractTask.java:308)
at CountedCompleter.exec(CountedCompleter.java:759)
at ForkJoinTask.doExec(ForkJoinTask.java:511)
at ForkJoinTask.invoke(ForkJoinTask.java:683)
at
ReduceOps$ReduceOp.evaluateParallel(ReduceOps.java:927)
at DistinctOps$1.reduce(DistinctOps.java:64)
at
DistinctOps$1.opEvaluateParallelLazy(DistinctOps.java:110)
at
AbstractPipeline.sourceSpliterator(AbstractPipeline.java:495)
at AbstractPipeline.evaluate(AbstractPipeline.java:264)
at
ReferencePipeline.forEach(ReferencePipeline.java:632)
at(#7:4)
```
On 2026-03-01 06:29, Jige Yu wrote:
Hi @core-libs-dev,
I am looking to validate the following idiom:
Stream.iterate(seed, e -> e.nextOrNull())
.takeWhile(Objects::nonNull);
The intent is for the stream to call nextOrNull()
repeatedly until it returns null. However, I am
concerned about where the Stream specification
guarantees the correctness of this approach
regarding happens-before relationships.
The iterate() Javadoc defines happens-before for
the function passed to it, stating that the action
of applying f for one element happens-before the
action of applying it for subsequent elements.
However, it seems silent on the happens-before
relationship with downstream operations like
takeWhile().
My concern stems from the general discouragement
of side effects in stream operations. For example,
relying on side effects between subsequent map()
calls is considered brittle because a stream might
invoke the first map() on multiple elements before
the second map() processes the first element.
If this theory holds, is there anything
theoretically preventing iterate() from generating
multiple elements before takeWhile() evaluates the
first one? I may be overthinking this, but I would
appreciate your insights into why side effects are
discouraged even in ordered, sequential streams
and whether this specific idiom is safe.
Appreciate your help!
Best regards,
Jige Yu
--
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
