Reactive Streams utility API

[James Roper]

Hi all,

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

https://github.com/lightbend/reactive-streams-utils

Regards,

James

On 22 February 2018 at 11:47, James Roper <james at lightbend.com> 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 ju.stream.Stream, 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
> JEP.
>
> Regards,
>
> James
>
> --
> *James Roper*
> *Senior Octonaut*
>
> Lightbend <https://www.lightbend.com/> – Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>
>



-- 
*James Roper*
*Senior Octonaut*

Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>