8181175 Stream.concat behaves like terminal operation

Paul Sandoz paul.sandoz at oracle.com
Mon Nov 20 18:34:22 UTC 2017

> On 17 Nov 2017, at 17:18, Stuart Marks <stuart.marks at oracle.com> wrote:
> Hi Paul,
> The normative text about binding to the source and subsequent modifications to the source possibly not being reflected in the stream makes sense.
> I'm having trouble understanding the API note though. What does "optimal" mean? What about concatenating multiple streams would not be optimal?

Yeah, you are in good company pointing that out :-)

I updated to:

* @apiNote
* To preserve optimization opportunities this method binds each stream to
* its source and accepts only two streams as parameters.  For example, the
* exact size of the concatenated stream source can be computed if the exact
* size of each input stream source is known.
* To concatenate more streams without binding, or nested calls to this
* method, try creating a stream of streams and flat-mapping with the
* identity function, for example:
* <pre>{@code
*     Stream<T> concat = Stream.of(s1, s2, s3, s4).flatMap(s -> s);
* }</pre>

We could support three or more streams while preserving some characteristics, that complicates the concatenating spliterator a little bit. Each stream would still need to be bound.

Patch updated to include the primitive streams:



More information about the core-libs-dev mailing list