Reactive Streams utility API

[Brian Goetz]

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.
>
> 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>
>>
>
>