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 WebSocket features with very high performance, and mapping that to the Reactive Streams API goes against that. Rather, I think that there should be a built in helper that allows Reactive Streams to be added on top, 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.
The use case here is how well this API will interact with other APIs. WebSockets are rarely used in isolation from other technologies. Most non trivial usages of WebSockets will involve plumbing the WebSocket API to some other source or sink of streaming data - for example, a message broker, a database, perhaps a gRPC stream to another service. The question is, how difficult will it be to connect those two APIs? Will their backpressure mechanisms map to each other easily? Will their failure handling and error handling semantics map to each other easily? How many lines of boilerplate will it take to hook them up? If the WebSocket provides an option to use Reactive Streams, then for any other sources/sink of streamed data that support Reactive Streams, application developers will have an option where the answers are guaranteed to be yes without the developer having to do any mapping themselves, and the lines of code to do that will be one. Regards, James On 22 March 2018 at 07:33, Chris Hegarty <chris.hega...@oracle.com> wrote: > 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] ): > http://cr.openjdk.java.net/~chegar/httpclient/02/javadoc/ > api/java.net.http/java/net/http/package-summary.html > > The webrev link has been refreshed to include implementation changes > to support the latest API, additional test code coverage and scenarios: > http://cr.openjdk.java.net/~chegar/httpclient/02/webrev/ > > > On 9 Feb 2018, at 14:33, Chris Hegarty <chris.hega...@oracle.com> wrote: > > Development of the JDK HTTP Client, incubated in JDK 9 and re-incubated > > in JDK 10, has continued. It will soon be in a position to be proposed > > for inclusion in Java 11, through JEP 321. This will proceed, as usual, > > through the JEP 2.0 process. > > > > JEP 321 has recently been updated with the proposed package and module > > name, `java.net.http`. The code in the sandbox has been updated to > > reflect this. > > > > Javadoc based on the latest code in the sandbox: > > http://cr.openjdk.java.net/~chegar/httpclient/00/javadoc/ > api/java.net.http-summary.html > > > > Webrev based on the latest code in the sandbox: > > http://cr.openjdk.java.net/~chegar/httpclient/00/webrev/ > > > > ( much of the changes in the webrev are mechanical due to renaming, but > > there are stability fixes and the API documentation has been > > reorganized to improve readability ) > > > > More information about the JDK HTTP Client can be found on the > > networking groups page. > > http://openjdk.java.net/groups/net/httpclient/ > > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8197565 > [2] https://bugs.openjdk.java.net/browse/JDK-8199938 -- *James Roper* *Senior Octonaut* Lightbend <https://www.lightbend.com/> – Build reactive apps! Twitter: @jroper <https://twitter.com/jroper>
