Moving CompletionHandler to java.util.concurrent

[Gili]

Hi,

I would like to propose moving CompletionHandler to package java.util.concurrent. Its use is not limited to I/O operations. For example, I use it for monitoring asynchronous Swing operations. CompletionHandler can be used virtually anywhere that java.util.concurrent.Future can, so why not place them in the same package?

Gili

[Alan Bateman]

Gili wrote:

> Hi,
>
> I would like to propose moving CompletionHandler to package
> java.util.concurrent. Its use is not limited to I/O operations. For example,
> I use it for monitoring asynchronous Swing operations. CompletionHandler can
> be used virtually anywhere that java.util.concurrent.Future can, so why not
> place them in the same package?
>
> Gili
>  

Have you brought this up on concurrency-interest? I'm pretty sure this
type of thing has come up many times (in the context of Executors at least).

-Alan.

[Gili]

Alan Bateman wrote:

Gili wrote:
> Hi,
>
> I would like to propose moving CompletionHandler to package
> java.util.concurrent. Its use is not limited to I/O operations. For example,
> I use it for monitoring asynchronous Swing operations. CompletionHandler can
> be used virtually anywhere that java.util.concurrent.Future can, so why not
> place them in the same package?
>
> Gili
>  
Have you brought this up on concurrency-interest? I'm pretty sure this
type of thing has come up many times (in the context of Executors at least).

I just cross-posted to http://www.nabble.com/Moving-CompletionHandler-to-java.util.concurrent-td25958440.html -- we'll see what they have to say. Oddly enough I couldn't find previous discussion of this sort of thing on their mailing list.

Gili

[Mark Thornton]

Gili wrote:
>
>  
> I just cross-posted to
> http://www.nabble.com/Moving-CompletionHandler-to-java.util.concurrent-td25958440.html
> -- we'll see what they have to say. Oddly enough I couldn't find previous
> discussion of this sort of thing on their mailing list.
>
> Gili
>  
Does the nabble interface work both ways --- your message hasn't yet
appeared on the 'real' concurrency list after an hour whereas it
appeared on the nio list within a minute or so.

Mark

[Gili]

Mark Thornton wrote:

Does the nabble interface work both ways --- your message hasn't yet
appeared on the 'real' concurrency list after an hour whereas it
appeared on the nio list within a minute or so.

Hi Mark,

It is normally instantaneous but in this case I forgot to subscribe to the forum prior to posting so my post is awaiting review by the moderator. It should be rectified within the next 24 hours.

Gili

[Gili]

http://www.nabble.com/Re%3A-Moving-CompletionHandler-to-java.util.concurrent-p25964609.html brings up a good point: why don't we simply add event listeners to Future? Seems like a much cleaner and more useful approach... Instead of having to provide one method for Future and another for CompletionHandler, the Future would handle both use-cases.

What do you think?

Gili

Mark Thornton wrote:

Gili wrote:
>
>  
> I just cross-posted to
> http://www.nabble.com/Moving-CompletionHandler-to-java.util.concurrent-td25958440.html
> -- we'll see what they have to say. Oddly enough I couldn't find previous
> discussion of this sort of thing on their mailing list.
>
> Gili
>  
Does the nabble interface work both ways --- your message hasn't yet
appeared on the 'real' concurrency list after an hour whereas it
appeared on the nio list within a minute or so.

Mark

[Gili]

You know what Alan? The more I take a look at http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/util/concurrent/ListenableFuture.html the more it doesn't make sense to introduce CompletionHandler in Java7. Instead of introducing duplicate methods (one that uses Futures, another that uses CompletionHandler) we should just have a single method that handles both use-cases using a ListenableFuture.

Have you guys reviewed this possibility already...?

Thanks,
Gili

Alan Bateman wrote:

Gili wrote:
> Hi,
>
> I would like to propose moving CompletionHandler to package
> java.util.concurrent. Its use is not limited to I/O operations. For example,
> I use it for monitoring asynchronous Swing operations. CompletionHandler can
> be used virtually anywhere that java.util.concurrent.Future can, so why not
> place them in the same package?
>
> Gili
>  
Have you brought this up on concurrency-interest? I'm pretty sure this
type of thing has come up many times (in the context of Executors at least).

-Alan.

[Alan Bateman]

Gili wrote:
> You know what Alan? The more I take a look at
> http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/util/concurrent/ListenableFuture.html
> the more it doesn't make sense to introduce CompletionHandler in Java7.
> Instead of introducing duplicate methods (one that uses Futures, another
> that uses CompletionHandler) we should just have a single method that
> handles both use-cases using a ListenableFuture.
>
> Have you guys reviewed this possibility already...?
>  
Yes, this ground has been well covered. If you go back a few years to
AIO4J, you'll see that it had an API that is close to what you are
suggesting now. The API we have now is relatively simple - you wait/poll
for a result using the Future, or you specify a callback (completion
handler) to be invoked when the I/O operation completes. There is no
support for "mixing" of styles where you might be waiting for the result
and also consuming the result in a callback, or where you decide to
register a callback after the fact. If you really need this then you can
wrap the channels and use the completion handlers to drive the framework.

-Alan.

[Gili]

Alan Bateman wrote:

Gili wrote:
> You know what Alan? The more I take a look at
> http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/util/concurrent/ListenableFuture.html
> the more it doesn't make sense to introduce CompletionHandler in Java7.
> Instead of introducing duplicate methods (one that uses Futures, another
> that uses CompletionHandler) we should just have a single method that
> handles both use-cases using a ListenableFuture.
>
> Have you guys reviewed this possibility already...?
>  
Yes, this ground has been well covered. If you go back a few years to
AIO4J, you'll see that it had an API that is close to what you are
suggesting now.

Okay, so why did the team decide against this approach? What problems are associated with it?

Alan Bateman wrote:

If you really need this then you can
wrap the channels and use the completion handlers to drive the framework.

I don't understand what you mean here. How can one wrap a channel to achieve the behavior I'm asking for?

Thanks,
Gili

[Alan Bateman]

Gili wrote:
> :
> Okay, so why did the team decide against this approach? What problems are
> associated with it?
>  
If you want a callback (or completion handler) to be invoked when the
I/O completes then you don't need a Future - just specify the completion
handler when initiating the I/O operation and don't create any objects
that could potentially be tenured. In terms of usage then it would be
strange to wait/poll for a result and at the same time be notified when
the I/O completes. In terms of performance it works well to dispatch
directly to the completion handler on the thread that is handling the
I/O event. If you are setting the completion handler after the fact then
it may require a slow-path wakeup of an I/O thread to ensure that the
completion handler is invoked on a thread with the correct identity
(unlike thread pools, the threads may be blocked waiting on I/O events
rather than work queues).

> :
> I don't understand what you mean here. How can one wrap a channel to achieve
> the behavior I'm asking for?
>  
It shouldn't be too hard to create a class that wraps a channel and
defines I/O methods that return "ListeningFuture"-like object. The
implementation will use the I/O methods that specify a completion
handler so that it is notified when the I/O completes. That notification
can be used to dispatch to the listeners, set the Future results, etc.
The only complication is listeners that are set after the I/O completes.
In that case it doesn't have a way to ensure that the listeners are
invoked on a thread with the expected identity.

-Alan.