Java 9 and IntSummaryStatistics et al.

[Peter Levart]

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.  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:

  public class SerializableIntSummaryStatistics extends 
IntSummaryStatistics implements Serializable {
     public SerializableIntSummaryStatistics() {
         super();
     }

     SerializableIntSummaryStatistics(long count, long sum, int min, int 
max) {
         super(count, sum, min, max);
     }

     Object writeReplace() {
         return new SerProxy(getCount(), getSum(), getMin(), getMax());
     }

     static class SerProxy implements Serializable {
         final long count, sum;
         final int min, max;

         SerProxy(long count, long sum, int min, int max) {
             this.count = count;
             this.sum = sum;
             this.min = min;
             this.max = max;
         }

         Object readResolve() {
             return new SerializableIntSummaryStatistics(count, sum, 
min, max);
         }
     }
}

Regards, Peter

>
> Chris
>
> P.S. On a more philosophical note - I have a generalized fear that the arrival of strong encapsulation is going to put much more stress on areas of the API where there is “insufficient” decoupling between the JDK as a set of common abstractions shared between consumers, and the JDK as an implementation of a common set of tooling.  In the past, the simplest solution to a bug was often break in to the JDK classes and tweak things.  Strong encapsulation in Java 9 is going to make that more difficult, more visible to end users, and gradually more unreliable (as the internals starts to move faster behind the scenes).
>
>
>> On Mar 29, 2017, at 11:44 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>>
>>> 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