stream() / parallel()

[Remi Forax]

On 11/27/2012 07:39 PM, Brian Goetz wrote:
> The "bun" operations of stream() and parallel() on Collections and 
> friends (which currently live in Streamable, but I am not sure that 
> Streamable carries its weight) work acceptably well for collections:
>
>   c.stream().ops(...)
> and
>   c.parallel().ops(...)
>
> The same thing works OK with the stream factories in Streams (which is 
> intended for use by libraries, not end-users):
>
>   Stream.stream(spliterator, flags)
>   Stream.parallel(spliterator, flags)
>   Arrays.stream(array)
>   Arrays.parallel(array)
>
> But we start to see friction in the other places where we surface 
> streams:
>
>   IntStream String.chars()
>   IntStream intRange(int start, int limit)
>   Stream<String> BufferedReader.lines()
>   <T> Stream<T> Streams.iterate(T seed, UnaryOperator<T> op)
>
> All of these are, currently, sequential streams.  But it seems an 
> unfortunate limitation that they are forced to be sequential.
>
> Duplicating these methods with parallel versions (i.e., 
> String.charsAsParallelStream) is possible but seems kind of yucky.
>
>
> Recent improvements in the Stream implementation (including the 
> strictures against "re-use") have created another possibility: an 
> explicit parallel() "op" on Streams.
>
> If this appears at the head of the stream, the performance cost is 
> almost zero (a few extra garbage objects at setup time), and on a 
> stream that is already parallel, it would be a no-op ("if (isParallel) 
> return this").

BTW, if you are allowed to return this here, it means that parallel() is 
not like any other methods of a stream that doesn't permit re-use/aliasing.

Rémi