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.san...@oracle.com> wrote:
On 29 Mar 2017, at 03:32, Remi Forax <fo...@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.den...@gmail.com>
À: core-libs-dev@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
