# streams.next / Stream Fusion

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.

Some of these shortcomings were conscious decisions by the expert group. We were aware of these:

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.

1. Parallel streams give everyday programmers FJ parallelism without the pain
2. 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:

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