RFR JDK-8087113: Websocket API and implementation
Roger Riggs
Roger.Riggs at Oracle.com
Tue Apr 5 16:37:57 UTC 2016
Hi Pavel,
Initial comments, bottom up.
It would be helpful if the classnames/filenames reflected the
participation in the WebSocket implementation
to keep them distinct from the HTTP 2.0 implementation in the same
directory.
For example, Writer, Reader, etc. perhaps a 'Ws' prefix would be
sufficient.
This would be alleviated if websocket was in its in its own package.
java.net.ws
(though I realize that may already have been settled, and I'm sure there
are some dependencies
that would be nice to keep as package private).
Logging is sprinkled throughout the APIs of the implementation; it would
be cleaner to have
a shared WS logging class with a static logger similar to the Http Log
(or perhaps some sharing and reuse)
so the logging does not clutter the implementation interfaces. It would
rare that separate logger
instances are needed.
Writer.java:
- line 143: keep track of the current/next buffer index of the first
non-empty buffer; instead of replacing with NULL_BYTE_BUFFER;
a combination of the buffers array index vs length and hasRemaining
could eliminate the need to copy the buffers array
and perform the initialization to determine the total length (though
that is informative for logging)
- not sure why you are using the 3 arg form of GatheringWriter since
the byteBuffers array is exactly the length.
- line 181: the assert would be more useful inside the loop; catching an
error when it occurs.
Assert reason is more useful with a short descriptive text.
- line 184: editorial, remove "from" from the logger
- line 228: can the Throwable be discarded? Does it contain no information?
Reader.java:
- line 137: Why should the reader force a new task? Should it be
left to the subscriber to
decide whether its processing is lightweight and can be done
immediately or to re-submit to its own executor.
java.net.Utils:
- line 231: SATURATING_INCREMENT (and its uses) is wasted code; long
is not going to roll over.
- line 236: NULL_BYTE_BUFFER isn't null - prehaps rename to
EMPTY_BYTE_BUFFER
$.02, Roger
On 3/25/2016 12:21 PM, Pavel Rappo wrote:
> Hi,
>
> Could you please review my change for JDK-8087113
>
> http://cr.openjdk.java.net/~prappo/8087113/webrev.03/
>
> This webrev contains initial implementation and basic tests for WebSocket API.
> Specification conformance & interoperability testing has been performed with
> Autobahn Testsuite [1]. As for API tests, I will provide more of them later.
>
> Thanks,
> -Pavel
>
> --------------------------------------------------------------------------------
> [1] http://autobahn.ws/testsuite/
>
More information about the net-dev
mailing list