Re: [ee4j-community] Approach to Reactive in Jakarta EE

[James Roper <james@xxxxxxxxxxxxx>]

Hi Ollie,

I don't think ADBA has completely abandoned juc.Flow, but they did raise some very important points - all the APIs proposed were practically unusable without a third party streaming library.

This is one reason why we need to discuss approach to Reactive in EE4J - the reality is that at the moment, support for juc.Flow is insufficient, neither the JDK, nor Jakarta EE (someone correct me if I'm wrong) should be providing APIs that require a third party application developer facing API in order to use them. Now, hopefully that will change, as there is work being done in the JDK right now to address this. So, there's nice green pastures in the future, if we plan it well. The question is, how do we ensure that the reactive APIs that we provide today are usable today when the tools are insufficient, but will also converge on something that is well integrated in future?

As a practical example, I think it would be inappropriate to introduce a new API today that relied 100% on Reactive Streams to be useful, but rather, a new API today should provide its own asynchronous abstraction that people can easily use today (perhaps heavily using CompletionStage), with a built in adapter like asPublisher() or asSubscriber() so that as Reactive Streams support gets better and more widespread in the Java standards, the API will be able to benefit from the seamless integration that Reactive Streams is designed for. Or an approach like JDK9 Http client might be useful, they use juc.Flow to consume/produce response/request bodies, but they provide out of the box implementations for the most common tasks, ensuring that the API is usable today without JDK support for building reactive streams, but also ensuring that as JDK support for Reactive Streams increases, what application developers can easily do with the HTTP client API will increase too.

Regards,

James

On 9 March 2018 at 02:15, Oliver Gierke <ogierke@xxxxxxxxxx> wrote:

Hi all,

thanks James for picking this up. An interesting read in that regard are these two threads [0, 1] on the ADBA (async alternative to JDBC) mailing list. The team has basically declared Flow not an option for APIs due to the lack of implementations within the JDK. At one point [2] Douglas even mentions that they consulted the JavaSE team and got recommended to stay away from Flow, which - if true - is a pretty interesting recommendation and a kill switch to truly reactive Java data access for at least the decade to come.

I know that strictly speaking JDBC is not a JavaEE (or Jakarta EE) standard but it's widely used in enterprise applications and directly ties into what's possible or not with JPA. We haven'T heard too much about that in the context of EE4J but I guess that's a topic for a different thread.

Cheers,
Ollie


[0] http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2017-October/000164.html
[1] http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2017-October/000184.html
[2] http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2017-October/000210.html

> Am 08.03.2018 um 12:08 schrieb James Roper <james@xxxxxxxxxxxxx>:
>
> Hi all,
>
> There are a number of different efforts in different Jakarta EE specs to provide support for reactive features. As many of you may know, I myself have been talking to and investigating a number of different places where Reactive Streams could be useful in Jakarta EE, but these efforts aren't limited to my work - JAX RS 2.1 introduces reactive features in the client, JSR 356 WebSockets support asynchronous streaming of messages, Servlet 3.0 introduced support for asynchronous sending of responses while Servlet 3.1 introduced asynchronous streaming IO. I've also talked to some spec implementers, such as CDI, who are interested in reactive features but aren't sure where to start.
>
> While it's great that this innovation is happening, there is a risk that all these efforts, being done in isolation, will produce a platform that doesn't integrate well with itself, and feels disjointed. For example, if messaging uses an asynchronous streaming API that is incompatible with the streaming offered by the WebSocket spec, then how are people meant to use these two APIs together? If the streaming API for response bodies offered by the JAX RS client is incompatible with the streaming API for response bodies offered by the Servlet spec, how are people meant to use these two APIs together?
>
> So I'd like to propose that we start an intentional effort of formalising an approach to reactive in Jakarta EE. What I think we should have answered is questions like:
> * When should an API use CompletionStage?
> * When should an API use Reactive Streams?
> * How should Reactive Streams based APIs be offered?
> * When should an API introduce its own mechanism/API for handling asynchronous data flows?
> * How should CDI context be addressed when much of the business logic of an application is moved to callbacks executed by unmanaged threads?
>
> I don't know what such an effort would look like in practice - the product might be a wiki page, or perhaps a document with code samples on GitHub. Maybe a dedicated mailing list is needed, or perhaps discussion can be had on another mailing list.
>
> Does this resonate with anyone? It's perhaps not on front of everyones minds right now, but it's something that needs to be addressed before mass adoption of reactive features in Jakarta EE happens, and as there are efforts currently in place, the sooner its addressed, the better.
>
> Regards,
>
> James
>
> --
> James Roper
> Senior Octonaut
>
> Lightbend – Build reactive apps!
> Twitter: @jroper

> _______________________________________________
> ee4j-community mailing list
> ee4j-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j-community

_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community

--

James Roper
Senior Octonaut

Lightbend – Build reactive apps!
Twitter: @jroper