Chris, On Mon, Apr 16, 2018 at 7:09 PM, Chris Hegarty <chris.hega...@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
