| Re: [ee4j-community] Approach to Reactive in Jakarta EE |
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
Attachment:
signature.asc
Description: Message signed with OpenPGP