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

[Chris Hegarty]

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 <chris.hegarty at oracle.com> 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 disagree is that it needs to be done in Java SE, let
>> alone in JEP 321.
> 
> Why is that ?
> There have been no problems in having Flow-based APIs for the HTTP
> client, so can you expand on why it would be different for WebSocket ?
> Not that I would like to have Flow-based APIs in WebSocket (it's
> indifferent for me, as long as the low-level API is there), I am just
> wondering why the difference.

You have been directly involved in the design of the WebSocket API
as it stands today ( not based on reactive streams Flow ). Are you
now suggesting now that Java SE should provide two programming
models for WebSocket? I think one is more than sufficient.

>>> with the understanding that such a helper will limit the capabilities and performance when its used - eg, the range of options for closing, range of options for how errors are handled, and perhaps introduce some small performance penalties such as additional allocations and/or buffer copies.
>>
>> That is a whole set of comprises and decisions that would need to
>> be considered.
> 
> Sure. However, such decisions have been made for the HTTP client.
> For example, the decision to use Flow-based APIs makes the HTTP client
> unsuitable to write an efficient HTTP proxy, as it will require data
> copies.

Writing an efficient HTTP proxy is not the primary use-case for
this API. It is being positioned as a replacement for the legacy
HttpURLConnection API. It needs to be approachable by the average
( whatever that is ) Java developer.

> What I see incongruent in JEP 321 is that it provides Flow based APIs
> for HTTP but not WebSocket, and low-level efficient APIs for
> WebSocket, but not for HTTP.

I disagree. WebSocket and HTTP are two distinct protocols, whose
use will likely be very different. I don't see why it is
incongruent to model them in different ways.

> If the focus is on the HTTP client, I'd rather see efficient APIs for
> the HTTP client since the HTTP proxy use case is quite common.

Answered above.

> The design decisions taken for WebSocket (low-level APIs; easily
> wrappable in Flow APIs; efficient with respect to data copy and
> allocation; based on CompletableFuture) should have been taken for
> HTTP with even more importance, given how more popular is HTTP over
> WebSocket.

I disagree. The WebSocket API is less approachable by the average
Java developer. It's low-level semantics and use of CompletableFuture,
while appropriate for libraries building on top or using it as a
transport, is acceptable. It is not something that I would expect
the large majority of Java developers ( likely to be retrieving HTTP
resources ) to be as comfortable with.

The substantive point is that the HTTP Client API and the WebSocket
API are targeting two different audiences.

> I would like this revision to be taken into consideration, offering an
> efficient low-level API for HTTP as well.

The HTTP Client API been based on Flow for for a long time now.
Incubated in JDK 9, and re-incubated in JDK 10. I note, that you
have been following and contributing to JEP 110 and now JEP 321
too ( your contributions have been very valuable, thank you ).

Offering a low-level HTTP API ( akin to that of WebSocket ) will
make the API less approachable to the majority of Java developers.
This is not something that I am comfortable with.

-Chris.