RFR JDK-8156742: Miscellaneous WebSocket API improvements

[Pavel Rappo]

Simone,

> On 31 May 2016, at 23:05, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> I think this class exposes too many failure codes that applications
> *must not* be able to use.
> For example, 1002 is not something that the application can ever send,
> only the implementation can, and having a public API to create a 1002
> CloseInfo is not something you I'd like to see exposed.
> Same goes with 1007, which the implementation must detect, not the
> application; etc.
> I would probably just leave CloseInfo.of(), with the current checks
> you are doing extended.

Good point. On the other hand, I was wondering if their semantics is definitely
bound to WebSocket Protocol itself? i.e. can they be reused to indicate
subprotocol issues, or pre-agreed format, etc.?

1002

      1002 indicates that an endpoint is terminating the connection due
      to a protocol error.

1007

      1007 indicates that an endpoint is terminating the connection
      because it has received data within a message that was not
      consistent with the type of the message (e.g., non-UTF-8 [RFC3629]
      data within a text message).

> Can't the implementation just synthesize a (1005, "") instead and get
> rid of the Optional ?
> Also, I think it should return a CF, for the following reason.
> Notification of onClose() is a half-close. Applications are entitled
> to send data from within onClose().
> For such reason, the implementation cannot send the response close
> frame just after the method returns.
> It should wait until the application has finished writing, and hence
> the need for the CF.

Here are some thoughts on this issue. It's a special value. It's not null, yes,
but it doesn't seem to be a lot better than it. If we allow this code to be
"received", it means we will probably have to allow it also to be sent, as one
can simply do this:

    @Override
    public void onClose(WebSocket webSocket, CloseReason code) {
        webSocket.sendClose(code);
    }

Why not? And if users can send it back, why can't they construct it? In any way
an implementation will have to maintain this illusion in both directions.
Namely, when one sends a Close message with "1005" (and maybe a non-empty
reason), the implementation will have to detect it, discard the data and send
instead an empty Close message.

It's not that obvious that
 
    ws.sendClose()
 
and

    ws.sendClose(CloseReason.of(1005, ""))
 
are the same. I think using `Optional` in this particular case is cleaner.

Thanks,
-Pavel