Experts,
I'd like to share some community feedback on the RX draft, collected from presentations about Jersey RX API, which is rather similar to the recent draft:
* The idea in general is understood and highly appreciated! :-)
* 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)"!
* 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"!
* 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, and how an application should detect whether any other is supported, and what to do if the particular one needed is not supported. Hence, I would rather say we stick with CompletableStage for the sake of the API specification, and clearly identify the "rx(Class)" variant as a product-specific feature of Jersey. If CXF and RestEasy like still implement it, OK, but it should not be part of the spec until the above questions are answered by the spc, too.
* 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. :-)
To sum up, what I expect that people want the API to look like is:
@Resource ManagedExecutorService CONTAINER;
…
Client<CompletableFuture> client = ClientBuilder.newReactiveClient(CONTAINER);
CompletableFuture<String> getA = client.target("some uri A").request().get();
CompletableFuture<String> getB = client.target("some uir B").request().get();
getA.thenCombine(getB, (a, b) -> a + ":" + b).join();
* 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, as the result produces eventually has to be returned to a caller in turn. There is no need to block that caller's thread meanwhile. We could just offload that task by internally using a CompletableFuture in turn, and let the Executor Service (hence the container) deal with it once the chain is resolved finally.
I hope this community feedback is of any value and that it does not imply too much technical problems to the vendors. Clearly it makes the application code more concise and stronger related to Java SE and Java EE.
Regards
-Markus
From: Santiago Pericasgeertsen [mailto:santiago.pericasgeertsen_at_oracle.com]
Sent: Montag, 12. Oktober 2015 16:30
To: 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
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/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
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