Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

On Tue, Apr 17, 2018 at 6:28 PM, Chris Hegarty wrote: > On 17 Apr 2018, at 17:52, Viktor Klang wrote: > > ... > > There is technical and non-technical effort required. It is non-trivial. > > That said, we’re making every effort possible to move

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

On 17 Apr 2018, at 17:52, Viktor Klang wrote: > ... > There is technical and non-technical effort required. It is non-trivial. > That said, we’re making every effort possible to move this forward. > > Hi Chris, > > how can we help? Thank you for asking, but I think we

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

On Tue, Apr 17, 2018 at 9:55 AM, Chris Hegarty wrote: > Simone, > > > On 16 Apr 2018, at 18:47, Simone Bordet wrote: > > > >> ... > > > > Out of curiosity, is this code implementing the ReactiveStreams TCK > > (in its Flow declination) ? > >

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Simone, > On 16 Apr 2018, at 18:47, Simone Bordet wrote: > >> ... > > Out of curiosity, is this code implementing the ReactiveStreams TCK > (in its Flow declination) ? The code should be compliant with the RS TCK. > I ask because I have recently implemented it for

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Chris, On Mon, Apr 16, 2018 at 7:09 PM, Chris Hegarty wrote: > Hi, > > Here are refreshed links to the latest code in the sandbox: > > http://cr.openjdk.java.net/~chegar/httpclient/03/javadoc/api/java.net.http/module-summary.html >

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi, Here are refreshed links to the latest code in the sandbox: http://cr.openjdk.java.net/~chegar/httpclient/03/javadoc/api/java.net.http/module-summary.html http://cr.openjdk.java.net/~chegar/httpclient/03/webrev/ Includes: a) Changes to address the two issues raised by Simone during the

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Michael, Chris, Thanks for your feedback, indeed with PublishingBodySubscriber, it works also for streaming use cases and it provides the behavior I was trying to achieve. So +1 for inclusion of JDK-8201186 in JDK 11. On Thu, Apr 5, 2018 at 6:12 PM, Chris Hegarty

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi Sebastien, > On 5 Apr 2018, at 11:07, Sebastien Deleuze wrote: > > Hi, > > I am currently implementing a draft support for JDK new HTTP client in Spring > Framework 5 [1] (using JDK 10 for now) in order to be able to leverage it as > a WebClient [2] engine. Great

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Sebastien, The answer depends on the particular HttpResponse.BodySubscriber/Handler implementation supplied to the sendAsync() call. Some of the simpler ones which return aggregate/completed objects like String, or byte[] do not appear to stream and the response body is not returned until

RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi, I am currently implementing a draft support for JDK new HTTP client in Spring Framework 5 [1] (using JDK 10 for now) in order to be able to leverage it as a WebClient [2] engine. Our integration tests all pass with regular HTTP/1.1 webservices (we have not tested the HTTP/2 support yet), but

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi Simone! :) I think James conveyed basically everything I had in mind to respond, but I felt compelled to address the following: >Forcing users to implement Subscribers or Processors (because that's what the API requires, despite having a few utilities that cover the common cases) is way more

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi, On Mon, Apr 2, 2018 at 12:39 PM, Chris Hegarty wrote: > I can find no material supporting this assertion on reactive-streams.org, > or anywhere else for that matter. This is not something that I have, or > any member of the HTTP Client team has, ever come across. We

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

James, perhaps I was not clear enough. The JDK will offer an API based on RS, so that's a user-facing API. Given that, the question is whether the surface of exposition to users when they want to use the JDK HttpClient API should be limited to Publishers, or expanded to Publishers, Subscribers

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi Simone, Thank you for your reply. I have inserted inline my replies to specific assertions and comments, but please continue to read on past these as there two concrete proposals further down that address your concerns, as I understand them. > On 30 Mar 2018, at 14:34, Simone Bordet

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi Simone, There are some RS implementations that offer a user facing API that only offers their equivalent of a Publisher to end users, but that is immaterial to RS, since RS is not an end user facing API, but an integration API. End users should not be implementing their own

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi, On Wed, Mar 21, 2018 at 9:33 PM, Chris Hegarty wrote: > Hi, > > This is a request for review for the HTTP Client implementation - JEP 321. It is my understanding, and that of the ReactiveStreams (RS) people I spoke with, that both the RS API and the higher level

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

On 28 March 2018 at 18:50, Wenbo Zhu wrote: > >>> Any useful RS support will have to involve some application-level >>> protocols. >>> >> >> I completely disagree with this statement. As someone who has been >> involved in/led the implementation of multiple WebSocket clients

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Simone, Thank you for you comments. On 23/03/18 08:28, Simone Bordet wrote: Hi, On Thu, Mar 22, 2018 at 1:57 PM, Chris Hegarty wrote: Rather, I think that there should be a built in helper that allows Reactive Streams to be added on top, I fully agree that a

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi, On Thu, Mar 22, 2018 at 1:57 PM, Chris Hegarty wrote: >> Rather, I think that there should be a built in helper that allows Reactive >> Streams to be added on top, > > I fully agree that a Reactive Streams WebSocket abstraction should be > built on top. Where I

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

James, Thanks for your reply. > On 22 Mar 2018, at 00:28, James Roper wrote: > > Hi Chris, > > I'm still really keen to see an option provided out of the box for using > Reactive Streams with the WebSocket API. What we are delivering in JEP 321 is mainly an HTTP Client

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi Chris, I'm still really keen to see an option provided out of the box for using Reactive Streams with the WebSocket API. Note that I'm not proposing that anything be changed about the existing API, I understand fully that you want to provide a full powered API that offers the full range of

RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi, This is a request for review for the HTTP Client implementation - JEP 321. The javadoc link has been refreshed, based on feedback received from the CSR [1] ( and a follow on supplementary CSR [2] ):