jsr356-experts@websocket-spec.java.net

[jsr356-experts] Possible API Cleanup in async send operations

From: Danny Coward <danny.coward_at_oracle.com>
Date: Fri, 01 Feb 2013 19:06:45 -0800

Hi folks,

This one's obliquely related to
(http://java.net/jira/browse/WEBSOCKET_SPEC-110), but also this has come
up elsewhere.

Currently we are using 3 classes for async sends:-

Future<SendResult>
     SendResult get()
     SendResult get(timeout, unit)
     cancel()
     isDone()
     isCancelled()

SendHander
     setResult(SendResult sr)

SendResult
     getException()
     isOK()

RemoteEndpoint
     Future<SendResult> sendXXXByFuture(message)
     void sendXXXByCompletion(message, SendHandler)

For the information transmitted during the async operation ("did it get
sent or not ?"), this is perhaps a little heavyweight. It also creates
an ambiguity when using the Future<SendHandler> if the operation fails:
does the exception get wrapped as the cause of the ExecutionException
thrown on Future.get(), or is it set on the SendResult ?

So here's a simpler alternative, which coveys the same information, but
with less API and no ambiguity:-

Future
     void get()
     void get(timeout, unit)
     cancel()
     isDone()
     isCancelled()

SendHandler
     void handleSendError(Throwable t)
     void handleSendCompleted();

RemoteEndpoint
     Future sendXXXByFuture(message)
     void sendXXXByCompletion(message, SendHandler)

A send failure using the Future method results in the Throwable being
wrapped as the cause of the ExecutionException thrown out of the
Future.get() method, which is, after all, the proper use for that.

I think its cleaner. Any other thoughts ?

- Danny
-- 
<http://www.oracle.com> 	*Danny Coward *
Java EE
Oracle Corporation