To answer the questions at the bottom: the next step is to start working on this and get folks excited about contributing.  There's plenty of time for process later, but filing a JEP or creating a project shouldn't be a barrier to innovating.

On 2/28/2018 10:33 PM, James Roper wrote:
Hi all,

We've put together a simple proposal for this. Please read the README for
an introduction to this proposal.



On 22 February 2018 at 11:47, James Roper <> wrote:

Hi all,

This is an email to give people a heads up that we'd like to look at
creating an API, in the same vein as the JDK8 Streams API, for building
reactive streams (a la JDK9 juc.Flow). Our goals for this are:

* To fill a gap in the JDK where if a developer wants to do even the
simplest of things with a JDK9 juc.Flow, such as map or filter, they need
to bring in a third party library that implements that.
* To produce an API that can build Publishers, Subscribers, Processors,
and complete graphs, for the purposes of consuming APIs that use reactive
streams (for example, JDK9 Http Client).
* To produce an API that aligns closely with, using it
for inspiration for naming, scope, general API shape, and other aspects.
The purpose of this goal is to ensure familiarity of Java developers with
the new API, and to limit the number of concepts Java developers need to
understand to do the different types of streaming offered by the JDK.
* To produce an API that can be implemented by multiple providers
(including an RI in the JDK itself), using the ServiceLoader mechanism to
provide and load a default implementation (while allowing custom
implementations to be manually provided). There are a lot of concerns that
each different streams implementation provides and implements, beyond
streaming, for example monitoring/tracing, concurrency modelling, buffering
strategies, performance aspects of the streams handling including fusing,
and context (eg thread local) propagation. This will allow libraries to use
and provide contracts based on this API without depending on a particular
implementation, and allows developers to select the implementation that
meets their needs.

Non goals:

* To produce a kitchen sink of utilities for working with reactive
streams. There already exist a number of reactive streams implementations
that seek to meet this goal (eg, Akka Streams, Reactor, RxJava), and once
you go past the basics (map, filter, collect), and start dealing with
things like fan in/out, cycles, restarting, etc, the different approaches
to solving this start to vary greatly. The JDK should provide enough to be
useful for typical every day streaming use cases, with developers being
able to select a third party library for anything more advanced.

We will update this list when we have something ready for public review.
This probably won't be far off. Our hope is that we can propose this as a



*James Roper*
*Senior Octonaut*

Lightbend <> – Build reactive apps!
Twitter: @jroper <>

Reply via email to