OCP JAVA SE 17 DEVELOPER PRACTICE TESTS - Streams reduce operation

Hi,

While doing the practice tests I have run into a couple of questions so far for which I do not agree with their solutions: Chapter 6 Question 34 option B; and Chapter 6 Question 41 option B.

For both questions to seem to be ok the parallel execution plan for the accumulation operation must satisfy that all threads are run on single-element chunks throughout the entire stream which, I must admit, seems to be the case when I have tested them as they are without introducing any change. As far as I know, there is no such warranty made by the Java Language Specification and in any case would be incoherent to do so because the serial execution model would yield a different result. Therefore, I take for granted that it is just a coincidence that at least they may seem to work fine because the two streams are pretty small, much smaller than the thread pool.

Anyway, if we look at the following test cases for Q.34 and option B it seems quite easy to figure out that the reduction operation can be solved by applying N * 5 where N is the length of the stream. That is exactly what we expect to see if the accumulator function has been applied one by one so that we end up combining as many intermediate results as elements are in the stream. The accumulator function would behave just as a transformation function which ignores any previous result.

public class MyClass {    public static void main(String args[]) {        // Prints 25        System.out.println(            java.util.List.of(1, 2, 3, 4, 5)            .parallelStream()            .reduce(0,                (a, b) -> 5,                (a, b) -> a + b)        );        // Prints 35        System.out.println(            java.util.List.of(1, 2, 3, 4, 5, 6, 7)            .parallelStream()            .reduce(0,                (a, b) -> 5,                (a, b) -> a + b)        );        // Prints 50        System.out.println(            java.util.List.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)            .parallelStream()            .reduce(0,                (a, b) -> 5,                (a, b) -> a + b)        );    } }

The first setback is that it is not coherent with the serial execution model as the next test case shows.

public class MyClass {    public static void main(String args[]) {        // Prints 5        System.out.println(            java.util.List.of(1, 2, 3, 4, 5)            .stream()            .reduce(0,                (a, b) -> 5,                (a, b) -> a + b)        );        // Prints 5        System.out.println(            java.util.List.of(1, 2, 3, 4, 5, 6, 7)            .stream()            .reduce(0,                (a, b) -> 5,                (a, b) -> a + b)        );        // Prints 5        System.out.println(            java.util.List.of(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)            .stream()            .reduce(0,                (a, b) -> 5,                (a, b) -> a + b)        );    } }

The second setback is that it is not consistent either once the parallelism threshold is exceeded as the next test case shows.

public class MyClass {    public static void main(String args[]) {        // Prints 180 instead of 350        System.out.println(            java.util.stream.IntStream.iterate(1, i -> i + 1)            .limit(70)            .boxed()            .parallel()            .reduce(0,                (a, b) -> 5,                (a, b) -> a + b)        );        // Prints 200 instead of 425        System.out.println(            java.util.stream.IntStream.iterate(1, i -> i + 1)            .limit(85)            .boxed()            .parallel()            .reduce(0,                (a, b) -> 5,                (a, b) -> a + b)        );        // Prints 240 instead of 500        System.out.println(            java.util.stream.IntStream.iterate(1, i -> i + 1)            .limit(100)            .boxed()            .parallel()            .reduce(0,                (a, b) -> 5,                (a, b) -> a + b)        );    } }

I also guess all these outputs depend on what JVM runtime implementation is used by the way.

The reduce method we are using states that the following condition must hold true for any accumulated 'u' value and stream element 't':

  combiner.apply(u, accumulator.apply(identity, t)) == accumulator.apply(u, t)

In this case we have that:

  identity = 0
  accumulator = (a, b) -> K
  combiner = (a, b) -> a + b

Then if we replace we get:

  u + K = K

Of course this condition can only be true for any u when K = 0, and in turn, will make that u = 0 as well because 0 + 0 = 0. But in option B it happens that K = 5.

It would help if you could quote the question, and the answer that you disagree with.

34. Given the following code snippet, which lambda expressions are the best choices for an accumulator? (Choose two)

import java.util.*; import java.util.function.*; public class GoodAccumulator {   int i = 0;   List<String> words = new ArrayList<>();   public void test() {      BiFunction<Integer, Integer, Integer> x = _______________;      System.out.print(List.of(1, 2, 3, 4, 5)      .parallelStream()      .reduce(0, x, (s1, s2) -> s1 + s2));   }   }

A. (a, b) -> (a - b)
B. (a, b) -> 5
C. (a, b) -> i++
D. (a, b) -> {words.add("awesome"); return 0;}
E. (a, b) -> {return 0;}
F. (a, b) -> words.add("awesome")

Solution is B,E.
I think it should be D,E.

I agree with you that B is false, because that accumulator is not compatible with the combiner.

I do not agree that D is true. While it's not forbidden that the accumulator has side-effects, it's strongly discouraged. I do think that D is a better choice than B.

In my opinion, the only good accumulator is E, so there's definitely something wrong with the question.

I do not know if someone is going to fix these mistakes, but Question 69 has the same issue.

For #34, I agree with Stephan that D is definitely wrong. In fact, all but B and E are terrible answers.

I made a note to see if we want to do anything about any of this in the next book. It's hard to come up with realistic parallelization examples in ways in small blocks of code.

Jeanne Boyarsky wrote:For #34, I agree with Stephan that D is definitely wrong. In fact, all but B and E are terrible answers.

I made a note to see if we want to do anything about any of this in the next book. It's hard to come up with realistic parallelization examples in ways in small blocks of code.

Cannot agree on that. B is much worse than D. A neutral side effect, even though discouraged, is still neutral. B does not follow method contract. It's really harmful.