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
