Hi Justin,
On 2/4/13 4:38 AM, Justin Lee wrote:
> A get() that returns void is an odd beast indeed.
I don't think so.... It simply models a process that either succeeds or
fails, which is sort of the case with the async sends we have. The
get()'s utility is in blocking until the process completes, or throwing
an exception if it fails, the utility in the Future is being able to
cancel or query the status of the process.
> If the get() is just to verify the send, perhaps it could be renamed.
> Calling it a Future would be odd, too, given that it doesn't follow
> the Future that people would expect.
Well, the JDK's Future class is supposed to be a general purpose API for
this kind of case. " A Future represents the result of an asynchronous
computation.". I think there are folks using it when the computation has
no particular result other than success and failure, as well as
Future<MyResult> when the result is more subtle.
The problem with what we have now is that the failure case is ambiguous,
and there's too much API for the information that's there.
if we ditched Future, we'd want to recreate the
success/failure(reason)/isDone()/isCancelled()/cancel() APIs in some
homegrown way. Might start looking like another Future !
- Danny
>
>
> On Sat, Feb 2, 2013 at 4:06 AM, Danny Coward <danny.coward_at_oracle.com
> <mailto:danny.coward_at_oracle.com>> wrote:
>
> 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
>
>
>
>
> --
> You can find me on the net at:
> http://antwerkz.com <http://antwerkz.com/> http://antwerkz.com/+
> http://antwerkz.com/twitter http://antwerkz.com/github
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation