Hi there,
I agree that we should agree on a reasonable API before adding it to the
spec forever. Especially the case with the Flow type will be an issue in
JDK 9.
I highly welcome that we want to work on smaller improvements though. As
there are already JIRA issues for these, should be compile a list sorted
by priority and start from the top?
Maybe everybody can vote on JIRA if they haven't already.
Cheers,
Sebastian
On 04/03/2017 06:40 PM, Pavel Bucek wrote:
>
> Dear EG members,
>
> As you all know we have been hard at work trying to come up with an
> NIO proposal based on Flows. In doing so, we have come to the
> conclusion that this is indeed a really hard problem --lots of small
> details that need double clicking! After some deliberation, we have
> come to the conclusion that it is better to drop this feature from
> this dot release. Here is the rationale for doing so:
>
> - Working backwards from the officially committed Java EE 8 release
> date - July 2017 - we need to start Public Review in the middle of
> April, which means that at this point we don't have enough time to do
> a design, implementation prototype and gather appropriate feedback.
> - Current proposal is based on a Flow-like API, which would force us
> to duplicate the JDK 9 Flow concept in the JAX-RS 2.1 API.
> - We don't want to introduce "just another non-blocking API", which
> might be deprecated very soon (when Java 9 is released).
> - We need some time to work on "smaller issues", which would be most
> likely not possible if we'll continue working on NIO.
>
> *What does that mean for the current state of the API?*
>
> We will remove Flow.* interfaces and its usage in existing APIs, which
> means adjustments in SSE part of the spec. Also, we will be making at
> least some improvement, more related to already introduced Reactive
> API - support for returning CompletionStage from the resource method.
> It was in our last version of the high level non-blocking API;
> CompletionStage is basically a Mono - publisher of a single item.
> Resource method could then look like:
>
> @POST @Path("acceptProduceSource")
> public CompletionStage<AnotherPOJO> echoNioEntity(POJO requestEntity) {
>
> // not blocking the thread, returning CompletionStage and doing the
> work elsewhere. return ...;
>
> }
>
> This improvement will simplify use of the new JAX-RS 2.1 reactive
> client API in a JAX-RS resource method. Note that this is already
> tracked as https://java.net/jira/browse/JAX_RS_SPEC-546.
>
> As always, any comments or suggestions are appreciated.
>
> Thanks and regards,
> Pavel & Santiago
>