Santiago,
please find my response inlined.
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.
I see your point, but there is a difference between async and rx from a conceptional view: Typically one will write a complete application in a reactive style COMPLETELY and will not mix reactive and non-reactive style in one single application (this would be like a hybrid using OOP and non-OOP). So it makes not much sense to repeat the rx() again and again. async is actually decided per method, as typically most methods are non-async but only SOME are async. So rx() makes sense when building a client, while async() typically makes sense only when building an invocation.
* 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.
I understand your vision, but the question is, whether we can provide a simple Java 8 support without adding the complexity needed solely for the sake of future flexibility? I mean, this goes a bit into premature optimization in the sense of D. E. Knuth: Wouldn't it be evil to specify an extension point before we know that we really will need it in future? What if Java 10 comes with a full-monty reactive support that completely is built ontop of CompletableStage, and no other framework actually will be of broad interest? We will then have to maintain a complexity level that is not needed.
* 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.
To paraphrase my proposal into your API style: .rx(EXECUTOR) :-)
* 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.
Do you have some example at hand which you can disclose so we better understand what your plans on server side are?
— Santiago
From: Santiago Pericasgeertsen [ <mailto:santiago.pericasgeertsen_at_oracle.com> mailto:santiago.pericasgeertsen_at_oracle.com]
Sent: Montag, 12. Oktober 2015 16:30
To: <mailto:jsr370-experts_at_jax-rs-spec.java.net> 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