[jax-rs-spec users] Re: Proposal to drop non-blocking I/O from JAX-RS 2.1

From: Sergey Beryozkin <>
Date: Tue, 4 Apr 2017 17:10:22 +0100

Hi Santiago
On 04/04/17 16:48, Santiago Pericas-Geertsen wrote:
>> On Apr 4, 2017, at 11:34 AM, Alessio Soldano <
>> <>> wrote:
>> Il 04/04/2017 17:17, Sergey Beryozkin ha scritto:
>>> Would it make sense to return to what was available in m01, what
>>> Santiago originally prototyped, and restrict to the server code only ?
>>> It would be a basic NIO support, without being too involved, yet it
>>> would allow JAX-RS users to tap into Servlet 3.1 NIO API.
>>> Future JAX-RS 3.0 (?) based on Java 9 will be Java 9 Flow/etc based
>>> which will be good, but it will be many years before it will happen.
>>> In meantime users would use a somewhat limited but yet functional
>>> server side NIO which will become a 'legacy' API in future JAX-RSs.
>>> IMHO it will be better than having no NIO at all
>> +1, a simple NIO support for now looks like a good idea to me too.
>> It's possibly too early to put the more advanced solution into the
>> spec; while I see the point on having something ready for the future
>> (and I'm sorry I'm coming late to effectively contribute on the that
>> effort), I think it also makes sense for the spec to consolidate over
>> a more advanced solution in a future version, perhaps once such
>> solution has shipped as custom extension in one (or more) JAX-RS
>> implementation(s) and has been used / verified in the field.
> We certainly discussed the original proposal while investigating
> alternatives. However, there are some problems with that approach as well:
> (1) It does not integrate as nicely with there rest of the JAX-RS
> pipeline (filters, interceptors, etc.) mainly because it is too stream
> oriented
Why not, one the server read side NIO is initiated after the resource
method is invoked.
On the write side it is initiated once MBW is reached (I linked you to
the CXF code which does it).
In both cases readers/writers, filters are checked
> (2) Supporting this approach and something similar to Flows may
> result in a “bloated” API with two disjoint solutions for related problems
I don't think there's any similarity here between m01 and what was
proposed later. m01 server NIO API is an entry level, basic NIO API
> Thus, we concluded that more experimentation is required in order to
> achieve a single, unified API.
> It goes without saying that JAX-RS is a standard API, and once
> something is added, it is needs to be supported basically forever.
> Thus, we shouldn’t add anything unless we have real evidence that “it
> works”.

It does work in CXF, I linked you to our code earlier. It works because
Servlet 3.1 NIO API works and I said all the m01 API offers is a simple
wrapper aroung Servlet 3.1 API. It is straightforward and indeed it
works alongside the filters/interceptors


> — Santiago
>>> On 04/04/17 14:49, Sergey Beryozkin wrote:
>>>> Hi Pavel
>>>> It's disappointing even though I appreciate the effort done so far.
>>>> Probably the most important feature we could've done and now we
>>>> will face +N (or more) years of waiting for JAX-RS be NIO ready,
>>>> and by the time it will happen everyone will already be using
>>>> Spring RS anyway who are charging ahead as we speak with top-class
>>>> Reactive support...
>>>> I don't know, we will have though SSE which not all browser
>>>> implement, I'd rather have only NIO instead of SSE.
>>>> The 'Flow' duplication argument is not convincing because I believe
>>>> you had a plan after all to get rid of it when we get to Java 9.
>>>> The mid of April constraints just highlights that the process once
>>>> again defeats us completing the work which was planned
>>>> Thanks, Sergey
>>>> On 03/04/17 17:40, 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
>>>>> As always, any comments or suggestions are appreciated.
>>>>> Thanks and regards,
>>>>> Pavel & Santiago