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
