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

[Simone Bordet]

Chris,

On Mon, Apr 16, 2018 at 7:09 PM, Chris Hegarty <chris.hegarty at oracle.com> 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
> http://cr.openjdk.java.net/~chegar/httpclient/03/webrev/
>
> Includes:
>
> a) Changes to address the two issues raised by Simone during
>    the JEP Propose To Target [1] [2].
>
> b) Changes to address review comments from dfuchs, prappo,
>    michaelm, and chegar [3].
>
> c) Several bug fixes, additional test coverage, and stability
>    improvements.

Out of curiosity, is this code implementing the ReactiveStreams TCK
(in its Flow declination) ?

I ask because I have recently implemented it for Jetty's Reactive
HttpClient (https://github.com/jetty-project/jetty-reactive-httpclient)
and found a few surprising failures.
It will be great if this can be done because all ReactiveStreams
implementations implement the ReactiveStreams TCK, and so there is an
assumed baseline of how these libraries should work that is beneficial
for interoperability.

The effort is not much: each Publisher/Processor/Subscriber
implementation should just extend a ReactiveStream TCK class
overriding a few methods, for example:
https://github.com/jetty-project/jetty-reactive-httpclient/blob/master/src/test/java/org/eclipse/jetty/reactive/client/internal/QueuedSinglePublisherTCKTest.java

The ReactiveStreams TCK does the rest.

Thanks !

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz