This week's book giveaway is in the Jython/Python forum.
We're giving away four copies of Hands On Software Engineering with Python and have Brian Allbey on-line!
See this thread for details.
Win a copy of Hands On Software Engineering with Python this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Liutauras Vilda
Sheriffs:
  • Tim Cooke
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Ron McLeod
  • Ganesh Patekar
  • salvin francis
Bartenders:
  • Tim Holloway
  • Carey Brown
  • Stephan van Hulst

Sybex OCP Java 8 Study Guide, Chapter 4, p. 195, Parallel Reduction with collect()  RSS feed

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

In the middle of page 195 it is said that processing the given example in parallel would only work if we didn`t care about the order of the result.

I think that this is not true. The of-Method produces an ordered stream and the collect-Method should be deterministic, so process the elements in the encounter order, since nothing else is stated in the JavaDoc. This should also hold for parallel processing. In fact, the JavaDoc of the method explicitly says: "Like reduce(Object, BinaryOperator), collect operations can be parallelized without requiring additional synchronization."

I tested the example using a parallel stream and got "wolf" like with sequential processing.
 
author & internet detective
Posts: 39054
714
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Arno Wr wrote:I tested the example using a parallel stream and got "wolf" like with sequential processing.


The question is whether that behavior is guaranteed or just "happens" to occur in a the current implementation of Java.
 
A. Wellner
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think if a method is deterministic or not shouldn't change from version to version. And for the collect-method I cannot find any hint in the Java-Docs that the method might not be deterministic for parallel processing, like there is for methods like findAny or forEach. In contrast the Java-Doc of the method says: "Like reduce(Object, BinaryOperator), collect operations can be parallelized without requiring additional synchronization". There's also a similar example given with StringBuilder. Also the documentation about mutable reductions at https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html#MutableReduction explicitly says: "We can use the same technique to parallelize mutable reduction as we do with ordinary reduction."

The wolf-example fulfills the common requirements for reduction operations stated in the Java-Docs (accumulator and combiner are an associative, non-interfering, stateless function and the supplier creates a new result container) - so there should be no problems with parallel processing.
 
Marshal
Posts: 62194
193
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

I don't have the full details of the question, but a four‑element Stream might not go parallel even if instructed so to do. Try a much larger Stream and see what happens.
 
My honeysuckle is blooming this year! Now to fertilize this tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
https://coderanch.com/t/704633/RavenDB-Open-Source-NoSQL-Database
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!