RFR JDK-8156742: Miscellaneous WebSocket API improvements

[Pavel Rappo]

Simone,

> On 1 Jun 2016, at 18:31, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> I'm not sure it's worth encouraging to write application data from a
> onPing() or onPong() listener.
> My take on the issue is that upon receiving a Ping, the implementation
> should send a Pong "as soon as it is practical".
> I don't think sending the Pong should be done from within onPing().
> The implementation should do it, and may even do it _before_ calling
> onPing(), internally.

True. Internally though, as an implementation detail, I'm thinking of enqueueing
Pong before the invocation of `onPing`, if the previous _automatic_ Pong has
been already sent. If the previous one hasn't been sent, the implementation will
just swap that Pong with the newer one. And when resulting Pong has been sent,
one more message is then requested.

This behavior should protected the outgoing queue [1] from bloating and also
respects the back-pressure.

> In this interpretation, onPing() can return void (no need for CF)
> because there is no need to wait for the CF to send the Pong: the
> implementation sends the Pong either before or just after onPing().
> The onPing() implementation can be empty, and there is no risk that
> overriding it, the Pong is not sent.

OK. The only thing is that I would leave returned CS from onPing/onPong.
Remember we discussed that CompletionStage (or CompletableFuture) serves the
purpose of an asynchronous feedback: "Hey, I'm done with this data". I think
this way an implementation has more power in optimizing internal buffer pools,
etc. I don't see any harm in that. My guess, most of the time these methods
won't be overridden.

> On the other hand, sending application data from onClose() can be
> important: a goodbye message, a message that says what was the last
> message processed by the peer (similar to the last_stream_id in
> HTTP/2), etc.

True.

--------------------------------------------------------------------------------
[1] Yes, in the next couple of weeks we're going to get rid of "one outstanding"
    write policy: https://bugs.openjdk.java.net/browse/JDK-8157273