users@jax-rs-spec.java.net

[jax-rs-spec users] Re: Reactive Programming - Community Feedback

From: Santiago Pericasgeertsen <santiago.pericasgeertsen_at_oracle.com>
Date: Mon, 19 Oct 2015 11:52:30 -0400

Hi Markus,

 Inlined …

> * The API draft enforces to provide the type of interface again and again because the "rx()" method is part of the invocation builder, not part of the client builder. In fact, if a program uses reactive programming, it is doubtful whether a client would really use different interfaces for reactive programming for its invocation. Most people agreed when I said, I would rather prefer to give the type of interface to the client builder, so all invocations built from that client provide the same reactive technology, without any need to repeat the "rx()" method for each invocation. An alternative proposal could look like this:
>
> ClientBuilder.newClient(TYPE) => no need to repeat ".rx(TYPE)”!

 The use of an rx() fits better with the rest of the fluent API. It is just another “modifier” like async(), that is, just another “invoker”. If you start from ClientBuilder, then why not do that for other invokers?

 In fact, the person that designed the original Jersey API liked this approach better as well, especially for the JAX-RS API.

>
> * Support for CompletableStage is definitively a must and as it is the sole reactive interface defined by Java SE 8, it clearly has to be the default. To make it most simple to use it, an alternative proposal could look like this:
>
> ClientBuilder.newReactiveClient() => no need to provide "TYPE”!

 OK, that’s just like rx().

>
> * For a general purpose product like Jersey it is certainly a good idea to be able to provide the type of reactive interface, so it can integrate with any reactive framework. But for a cross-product specification, in particular for one that is an integral part of Java EE, it is doubtful whether this is a good idea: It opens up the question, which frameworks a JAX-RS implementation MUST support,

 Easy, only Java 8. I think reactive APIs are still evolving, so an extension point to allow future APIs to work with JAX-RS (without the need to rev the spec) would be useful.

> * There will be cases when it is MANDATORY or wanted to have the reactive framework execute the declared tasks using a particular thread group. For example, in Java EE any potentially blocking or long-lasting processing should be done by the managed executor service (in some container types you even MUST do that), so the container has full control of thread count, will never run out of threads, etc. Due to this, there must be a way to provide an executor. As this executor typically will be the same for all clients and all invocations, it would be best for the programmer to write it like this alternative proposal:
>
> ClientBuilder.newReactiveClient(EXECUTOR) ==> will use the provided executor, which typically is in injected ManagedExecutorService on JavaEE.
>
> Having said that, it might be beneficial if JAX-RS would detect that it runs in a Java EE container and simply by default us the default executor service provided since Java EE 7 through a container SPI. :-)

 Agreed.

>
> * The code snipped Santiago was pointing to does not showcase how to use RX on server side. In particular, it might be useful to glue together pending CompletableFutures with @Asynchronous,

 @Asynchronous is not part of JAX-RS, only Jersey. Other examples using AsyncResponse are very easy to write.

— Santiago

> From: Santiago Pericasgeertsen [mailto:santiago.pericasgeertsen_at_oracle.com <mailto:santiago.pericasgeertsen_at_oracle.com>]
> Sent: Montag, 12. Oktober 2015 16:30
> To: jsr370-experts_at_jax-rs-spec.java.net <mailto:jsr370-experts_at_jax-rs-spec.java.net>
> Subject: Drafts for Rx, NIO and SSE
>
> Dear Experts,
>
> My apologies for sending all these drafts in one shot, but I feel we need to start making progress quickly if we want to produce an EDR in a few months.
>
> The following pull request [1] includes proposals for Rx, NIO and SSE. Let me point you to the examples to get you started:
>
> (1) Rx:
>
> https://github.com/spericas/api/blob/master/jaxrs-api/src/test/java/javax/ws/rs/core/RxClientTest.java <https://github.com/spericas/api/blob/master/jaxrs-api/src/test/java/javax/ws/rs/core/RxClientTest.java>
>
> This is an extension to our Client API that integrates with the CompletableFuture API in JDK 8 (note that CompletionStage is a super type of CompletableFuture). The proposal is extensible and can use other APIs similar to CompletableFuture —see the optional parameter to the rx() method for that purpose. The spec will only mandate support for CompletableFuture, but implementations are free to provide support for other APIs, such as RxJava.
>
> (2) NIO:
>
> https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResource.java <https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResource.java>
> https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResourceClient.java <https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResourceClient.java>
>
> On the server side, the proposal follows the pattern set by StreamingOutput, but of course using lambdas this time around. As you know, Servlet already supports NIO, but with a completely different API.
>
> (3) SSE:
>
> https://github.com/mpotociar/api/tree/master/examples/src/main/java/jaxrs/examples/sse <https://github.com/mpotociar/api/tree/master/examples/src/main/java/jaxrs/examples/sse>
>
> Note that like in NIO, there are proposed extensions to both the Client and Server APIs for SSE.
>
> I understand that this is a lot to digest, so feel free to start new e-mail threads to discuss each one independently. I just felt it was important to start all these discussions ASAP.
>
> — Santiago
>
> [1] https://github.com/jax-rs/api/pulls <https://github.com/jax-rs/api/pulls>