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
Sergey
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 https://java.net/jira/browse/JAX_RS_SPEC-546.
>>
>> As always, any comments or suggestions are appreciated.
>>
>> Thanks and regards,
>> Pavel & Santiago
>>
>