On 2/4/13 4:28 PM, Danny Coward wrote:
> 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.
Just on this, Jitu reminded me of a use of Future<Void> in the JDK for
modelling a process (like ours) which either completes or raises an error
http://docs.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousSocketChannel.html#connect%28java.net.SocketAddress%29
- d
>
>> 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
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation