Java 9 and IntSummaryStatistics et al.

[Paul Sandoz]

> On 29 Mar 2017, at 03:32, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Seems a nice Math exercise.
> if you have the min, the max, the count and the sum, how to re-create an IntSummaryStatistics knowing you can only uses accept ?
> 
> What about calling accept() with the min, the max and (count - 2) times the (sum - min - max) / (count - 2) ?
> Obviously, if the remainder is not empty, you have to correct the error.
> 

That’s an interesting exercise to reproduce the state, but one has to hold ones nose when doing it :-)

An alternative, if possible, would be to avoid the use of IntSummaryStatistics (and others) and write your own serializable wrappers.

IntStream.summaryStatistics() is implemented as follows:

  public final IntSummaryStatistics summaryStatistics() {
      return collect(IntSummaryStatistics::new, IntSummaryStatistics::accept,
                     IntSummaryStatistics::combine);
  }

Paul.

> Rémi
> 
> ----- Mail original -----
>> De: "Chris Dennis" <chris.w.dennis at gmail.com>
>> À: core-libs-dev at openjdk.java.net
>> Envoyé: Mardi 28 Mars 2017 16:29:14
>> Objet: Java 9 and IntSummaryStatistics et al.
> 
>> Hi All,
>> 
>> I’m currently working on a project thats attempting to do a lot of heavy lifting
>> work with Java Streams (implementing, extending, adapting, etc). One issue we
>> ran in to is the inflexibility around  unmarshalling the IntSummaryStatistics
>> class (and it’s other primitive variations). I had originally decided to not
>> push on this since it had already been filed as a enhancement request and
>> dismissed (JDK-8043747) and since in Java 8 and earlier it wasn’t a huge
>> problem for us as we could use reflection to force the initialization of one of
>> these objects without much issue (modulo SecurityManager usage).  In Java 9
>> this starts to get much more unpalatable.  I’m left with having to open up
>> parts of the java.base module in order to get to what I need (in classpath mode
>> this looks particularly ugly since I have to open up to ALL-UNNAMED).  What I’m
>> trying to do here is get a roadmap in place for how to approach these kinds of
>> problems in a Java ecosystem which is (presumably) moving towards a gradually
>> more strict position on strong encapsulation.
>> 
>> Right now code that treats a stream pipeline as anything more complex than a
>> ‘literal’ pipeline of operations through which events are pushed is going to
>> hit this problem - a simple example would be any kind of calculation being
>> performed in advance of stream creation.  Right now the lack of interface
>> decoupling here means I have no choice but to ‘brute-force’ all these
>> calculations.
>> 
>> Thanks,
>> 
>> Chris Dennis