On 12/16/2008 11:34 AM, Jeanfrancois Arcand wrote:
> I would still think we need to manipulate Future and not specialized
> IOFuture. Note that we started jsr 203 with IOFuture and we dropped them
> to only use Future. I think this is more clearer...
The problem with Future is that it is not suited to I/O operations. The
"cancel" operation is intended to be invoked by someone who controls the
target thread ("mayInterruptIfRunning"), and it is not clear whether this
operation should block - the docs seem to imply that it does, so there's no
way to asynchronously cancel an I/O task (which is silly - that's the whole
use case of an async API!). Imagine a Swing app with a cancel button. If
you click on the button and your cancel operation is blocking, the whole
app is screwed unless you spawn the cancel off into another task.
Also, j.u.c.Future doesn't have a built-in notion of callbacks - NIO.2 has
to bolt this on, which is sloppy in my opinion. And it limits you to only
one CompletionNotifier.
And there's no way to ascertain whether the operation failed unless you do:
try { future.get(); } catch (ExecutionException ex) { ..now unwrap and
cast the cause, yuck.. }
And there's no way to wait for completion *without* getting the result!
There's also no way at all to wait uninterruptibly. You have to implement
this yourself.
This may be fine for regular tasks. But I've found it to be sorely
inadequate for I/O purposes. People are using it because it's there, not
because it's the right tool for the job. I think I/O is a big enough
umbrella to merit its own interface. :-)
- DML