8181175 Stream.concat behaves like terminal operation
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:
* 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:
* Stream<T> concat = Stream.of(s1, s2, s3, s4).flatMap(s -> s);
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