Viktor, I would like to address your first comment only, as your question is directed to someone else.
> On 6 Dec 2017, at 10:01, Viktor Klang <viktor.kl...@gmail.com> wrote: > .. > I think you raise some valid concerns, particularly with the byte buffer > pools. The conversation got off to a bad start as there was a misunderstanding about what was actually being proposed, so I would like to clear that up. The reference to byte buffer pools is not relevant here. They were introduced as a performance optimization that allowed better reuse of byte buffers between the socket channel and the SSL engine, in the implementation. That's all, nothing more. They have no bearing on the API, and this JEP is not proposing to make any changes in the NIO area. What is relevant is the use of byte buffers as a Flow of request and response body data. The API provides no mechanism for reuse, or pooling, of these byte buffers ( it did in a previous revision but was removed because of its complexity ). The latest version of the API for BodySubscriber [1] contains the following: “... the ByteBuffers, once passed to the subscriber, are no longer used by the HTTP client.”, and the BodyPublisher [2] contains: “Instances of ByteBuffer published by the publisher must be allocated by the publisher, and must not be accessed after being handed over to the library.". I accept that this could be made more clear in the API. The API uses byte buffers as carriers of data in a way that is consistent with other APIs. In the case of the publisher, it is the responsibility of the user to allocate the buffer and pass it to the HTTP Client, after which it should not be modified by user code. In the case of the subscriber, once the byte buffer is passed to `onNext`, it is then the sole responsibility of the subscriber. The primary motivation for the use byte buffers, as described above, is to provide maximum flexibility to an implementation to avoid copying and buffering of data. --- Through contacts from Viktor, we have recently received some feedback on the use of the body subscriber and publisher in the API. This feedback is very helpful and we will soon send out a proposal that will better support integration with existing publishers and subscribers. [ I will work with Viktor to bring this to the mailing list ]. -Chris. [1] http://cr.openjdk.java.net/~chegar/httpclient/javadoc/api/jdk/incubator/http/HttpResponse.BodySubscriber.html [2] http://cr.openjdk.java.net/~chegar/httpclient/javadoc/api/jdk/incubator/http/HttpRequest.BodyPublisher.html
