On Jan 14, 2013, at 4:47 PM, Peter Levart <peter.lev...@gmail.com> wrote:
> On 01/14/2013 04:06 PM, Paul Sandoz wrote: >> On Jan 14, 2013, at 3:38 PM, Peter Levart <peter.lev...@gmail.com> wrote: >> >>> I think these classes are targeted at use cases such as gathering real-time >>> statistics of profiling or business data, where data comes in from various >>> sources in real-time and statistics are sampled in real-time too... >>> >>> For bulk processing, the new streams API seems more appropriate. I think >>> the user might be able to control the order of operations applied >>> (j.u.stream.Spliterator API indicates that the spliting of work among FJP >>> threads could be controled and we can hope that the order of reduction of >>> intermediary results would also be controllable by the user or at least >>> defined). >>> >>> Can streams API developers shed some light on that? >>> >> DoubleStream (when added) will have a sum method that will defer to a >> reduce, so elements will be processed in order, but the grouping of elements >> depends on how the input is split and to what depth, and the user will have >> no control over that. > Unless user implements his own Spliterator, right? > To some extent. A Spliterator can split or say "I ain't gonna split no further!" but the framework may decide not to split before the Spliterator says no. IMHO i think a good Spliterator should keep on splitting until it reaches the limits of it's data and grouping wise it is best if a balanced tree is produced. Also it is worth pointing out that type of elements supplied by the spliterator may not be the same type of elements to reduce on. FWIW i was assuming 95% of users will never see a Spliterator. Paul.
