That sounds like implementation details. You may find something in the book by Urma Fusco and Mycroft I quoted earlier.
Gerard Gauthier wrote:. . . . How does collections work with a parallel stream when the input is sorted? . . . .
Stephan van Hulst wrote:Do you mean separate accumulations, rather than separate streams?
When a stream is split by a spliterator, it yields a second spliterator, not a second stream. When you perform a reduction or collection operation on a stream, each spliterator will yield an accumulation, and all separate accumulations must be combined with each other. If you have a sorted stream and you're performing a parallel reduction on it, it will be guaranteed that all reduced elements from a prior accumulation will be less than all reduced elements from a succeeding accumulation.
Stephan van Hulst wrote:Yes. But that's a given since you can't get a stream from a data structure in the first place if it can't create spliterators. And you can't call reduce() unless you have a stream to call it on.
All iterables implement a spliterator() method.
Well, that is how a Spliterator works. To reduce it to its very simplest terms, it can split a source into smaller bits and iterate each of those bits. The parallel() method uses a Spliterator to divide the source into bits, maybe 1024 elements each , but probably a different size, and successive bits are sent to the different threads in parallel. As we said earlier, it is very easy for a Spliterator to divide an array, an arrayed list or a balanced tree into smaller parts. It is very awkward to divide a linked list into such smaller parts, because you have to iterate the list 1023× to find the 1024th element.
Gerard Gauthier wrote:. . . . I am the Spliterator! I will divide you and conquer your smaller bits.