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

From: reza_rahman <>
Date: Thu, 06 Apr 2017 10:20:03 -0400

Thanks for your kind answer. I did in fact mean JAX-RS implementers.
-------- Original message --------From: Pavel Bucek <> Date: 4/6/17 9:56 AM (GMT-05:00) To: Subject: [jax-rs-spec users] Re: Proposal to drop non-blocking I/O from JAX-RS 2.1

    There are no stupid questions.
    If you mean "jax-rs providers", the answer would be "no, but its
      not simple". JAX-RS uses InputStream and OutputStream to
      process/produce HTTP entities and those APIs are blocking. There
      is no good way how to overcome that, InputStream#read(..) can
      block there is no way how to get the information whether it will
      block or don't read if there is no data to be read.
    OutputStream#write is almost the same. The difference is that in
      practice, this is not that big a deal, since outgoing connection
      usually do caching on different levels and the application already
      has the data to be written. Anyway, same statements are valid here
      - there is no method which would say whether #write will be
      blocking and when is no way how to do write in non-blocking
    There are possibilities how to do this even without support from
      the API, but it would most likely require new process for
      reading/writing entities (MessageBodyReader and
      MessageBodyWriter), which is significant alteration for the apps
      compared to the spec-compliant approach.
    If you mean "jax-rs implementations", I could imagine providing a
      support for consuming and producing Publisher<ByteBuffer>
      (or something like that) and documenting that MBR/MBW won't be
      part of the chain if that happens and see whether that is a useful
      or popular way how to design resource methods and include
      additional support based on that. Then the answer is just "no".




    On 04/04/2017 18:03, reza_rahman wrote:

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





        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

            - We need some time to work on "smaller issues", which would
            be most likely not possible if we'll continue working on
          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