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

From: reza_rahman <>
Date: Tue, 04 Apr 2017 12:03:38 -0400

I am sorry if this is a stupid question. Is there actually anything stopping providers from starting to implement NIO outside of the standard?
-------- Original message --------From: Sergey Beryozkin <> Date: 4/4/17 11:17 AM (GMT-05:00) To: Subject: [jax-rs-spec users] Re: Proposal to drop non-blocking I/O from JAX-RS 2.1

    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

      In meantime users would use a somewhat limited but yet functional
      server side NIO which will become a 'legacy' API in future


      IMHO it will be better than having no NIO at all





      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

          - 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:
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