8181175 Stream.concat behaves like terminal operation

[Paul Sandoz]

> 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:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8181175-concat-eager-binding/webrev/

Thanks,
Paul.