streams.next / Stream Fusion

JCrete 2015

streams.next / Stream Fusion

Home  |  Participants  |  Open Spaces |  Topics  |  Space-time Matrix  |  Blog  |  Excursions  |  Reflecting Forward

streams.next / Stream Fusion
Convenor: Cay Horstmann, Alex Petrov
Participants: (sorry, didn't keep track)
Summary: We talked about some shortcomings of java.util.stream in Java 8. It is surprisingly difficult to turn an iterator into a stream, and it requires an API that is described as "mostly for library writers" (http://www.lambdafaq.org/how-do-i-turn-an-iterator-into-a-stream/) There is no zip. (http://stackoverflow.com/questions/17640754/zipping-streams-using-jdk8-with-lambda-java-util-stream-streams-zip) Other than concatenation, there is no easy way of merging streams There is no easy way to create a finite stream from a generator function There is no easy way to get a stream of lines from a file that is backed by a memory-mapped buffer (may change in Java 9 according to Maurice Naftalin) It is not obvious how to change the FJ pool for parallel streams (http://stackoverflow.com/questions/21163108/custom-thread-pool-in-java-8-parallel-stream) Scala has useful operations on sequences (such as sliding windows, grouping) that Java lacks Some of these shortcomings were conscious decisions by the expert group. We were aware of these: zip existed at one time but was removed since it can be better implemented once Java has value classes (http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-June/002028.html) Because iterators and iterables should sometimes produce Stream, sometimes (Int/Long/Double)Stream, it was felt that putting a stream method into Iterator/Iterable was problematic (http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-June/002031.html) There isn't much going to change in Java 9. There is just one known new method in j.u.s: to turn an Optional into a Stream of length 0 or 1. Not a game changer :-) We noted that there are two distinct use cases for streams. Parallel streams give everyday programmers FJ parallelism without the pain Streams (parallel or not) can yield a more natural formulation than the equivalent loops ("what, not how") Perhaps surprisingly, the first use case is quite narrow. For stream parallelization to be effective, the data source must be in-memory the stream operations must be CPU-intensive ** They must not block ** The work must be sufficient to pay for setting up the computation These use cases exist, but they are not common in business applications. In an app server in particular, it seems unwise to go full-bore utilising all cores in a servlet response :-) That makes the second use case far more compelling for streams, and it would be nice to have more comfortable stream operations in the API. There are several libraries that aim to improve on Java 8 streams. The following came up: LazySeq ProtonPack jOOλ JavaSlang
Recommendations: Recommendations go here It makes sense that the initial rollout of j.u.s was conservative Don't get hung up over parallel streams--they have limited use Try some of the "better streams" libraries
Back to Space-time Matrix