-
JEP Task
-
Resolution: Delivered
-
P5
WebSocket API tasks
- Provide more examples in the API
RemoveText
interface andsendText(ByteBuffer)
: JDK-8156650Specify it's up to implementation how to treat incomplete (UTF-16 representation)CharSequence
s: JDK-8156650Remove word immediately everywhere from methods that returnCompletableFuture
: JDK-8156693CompletableFuture<WebSocket>
instead ofCompletableFuture<Void>
: JDK-8156693All exceptions other thanNPE
andIAE
should be relayed throughCompletableFuture
rather than thrown on the spot: JDK-8156693Provide better design foronPong
(take care of as much as possible in the implementation rather than delegate to theListener
): JDK-8159053Provide better design foronClose
(e.g. returnCF
to indicate when close can be sent): JDK-8159053Builder.connectTimeout(Duration)
instead ofBuilder.connectTimeout(long, TimeUnit)
: JDK-8156742void request(long)
instead oflong request(long)
: JDK-8156742RemovesendBinary(byte[], boolean)
: JDK-8156742RemovesendText(Stream<CharSequence>)
: JDK-8156742Specify it's up to an implementation to serialize Ping, Pong and Close messages with Text and Binary ones however it wants. Given the relative order of messages of the same type (control/non-control) is preserved.One outstanding write. Period.RemoveCloseCode
and use simple(int, String)
: JDK-8159053Return an emptyString
for no subprotocol rather thannull
ifonClose(1006)
is signalled instead ofonError()
, then
onOpen (onText|onBinary|onPing|onPong)* (onClose|onError)?
could be more strict
onOpen (onText|onBinary|onPing|onPong)* onClose|onError
WebSocket implementation tasks
Better check subprotocol syntax. Check for separators like"(" | ")" | "<" | ">" | "@",
- Think of repeated reading from the channel until the buffer is full or a message is received -- which comes first (optimization).
Default implementation of
Listener.onError
must log the error or do something likedefault void onError(WebSocket webSocket, Throwable error) { Thread.currentThread().getUncaughtExceptionHandler() .uncaughtException(Thread.currentThread(), error); }
Or make it abstract.
- Get rid of
ByteBuffer
pooling on the receiving side for binary messages as an error-prone activity for user.ByteBuffer
s can be stored by the user and reused. Bottom line. Slicing? Yes. Pooling? No! At the same time it's absolutely fine to poolCharBuffer
, since they are exposed asCharSequence
. AndCharSequence
is implementable, thus we can control access to an already disposed sequences. Own package for the implementation instead ofWS
type prefix.- Consider changing one-off registration with key cancellation for modifying
interestOps
(see Java™ NIO, 4.5 Selection Scaling); maybe we should put scalability one level higher, i.e. each channel reading/writing task is submitted to an executor? Is key cancellation followed by registration is expensive compared modifyinginterestOps
for the duration of the task? - Provide better exception messages, more descriptive and capturing state.
Unbounded queue for outgoing messages: JDK-8157273Decided not to do this.Delegate forbidden (used by RFC 6455) headers checking toIt's fine the way it is now.HttpClient
's internals (mainly because of the case-sensitivity rules)Consider pros and cons of attempting to send from the same thread followed by asynchronous sent of leftovers. Investigate possible problems with stack bloating.- Consider
ByteBuffer
pooling on the sending side. - Provide security checks for
sendXXX
. - Move UTF-16 to UTF-8 encoding operations to a point before message acceptance. So these errors become non-fatal: JDK-8156693
Test
- Group all tests in a dedicated folder
- Tests must be parametric (i.e. do not have a hardcoded data) where possible
Wordsmithing
abort()
andisClosed()
should agree on terminology. Use either of "TCP connection" or "socket"1. Work out a better notation forsendX/onX
in the javadoc. MaybesendType/onType