RFR 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder

[Paul Sandoz]

On Jan 14, 2013, at 4:47 PM, Peter Levart <peter.levart at gmail.com> wrote:

> On 01/14/2013 04:06 PM, Paul Sandoz wrote:
>> On Jan 14, 2013, at 3:38 PM, Peter Levart <peter.levart at 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.