Java 9 and IntSummaryStatistics et al.

[Paul Sandoz]

> On 29 Mar 2017, at 10:22, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Chris,
> 
> On 03/29/2017 06:06 PM, Chris Dennis wrote:
>> Remi: I really have to squint pretty hard to see that as anything other than “brute-force” - it’s still an O(N) calculation.
>> 
>> Paul: Right - but if I’m trying to implement the Streams API directly thats pretty much a non-starter, right.

Agreed.


>>  I think at this point the simplest change here would be to remove the final modifier from the accessor methods on the classes.  That way I can unmarshal in to a subclass that overrides the accessor methods (and makes the combine and accept methods throw UOE).  That obviously limits what can be done with the resultant instance, but it at least allows for a useful “read-only” behavior on return from a terminal stream operation.  It might also be possible to retain some of the combine functionality if the base methods accessed state through the instance methods rather than directly but that would not be “required” (and would be complicated in the case of Double).
> 
> An alternative would be to introduce a protected constructor taking (count, sum, min, max) parameters so that a serializable subclass could do the following:
> 

Yes, you beat me to replying (the thought occurred while i was cycling to work :-) ). Although i would argue a public constructor is just fine, which also performs some simple checking of the arguments.

Paul.