dev@grizzly.java.net

Re: [2.0] Unifying Future

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Tue, 16 Dec 2008 18:26:10 +0100

Hi,

>
> I would like to propose a change to the current Grizzly 2.0 way of
> using Future. Instead of having:
>
> IOFuture
> ConnectFuture
> ReadFuture
> WriteFuture

All these futures implement Future. Those classes just help us avoid
using casting or generics. However even with current Grizzly 2.0
implementation you can use just Future and don't care about its
subclasses.
Code:
ConnectFuture future = connectionHandler.connect();
Connection connection = future.get();

is the same as:

Future<Connection> future = connectionHandler.connect(...);
Connection connection = future.get();

The same situation with read and write. So, IMHO, it should be fine?
It just depends on developer's style.


> I would like to align with the API and remove the above classes and
> instead add something like GrizzlyFuture. Looking at the code, the
> specialized API added to the above classes can be replaced with
>
> public R get() // Instead of getResults, which return the same as
> get anyway.
getResult() is not the same as get().
getResult() returns result immediately, possibly null if result is not
ready yet.

> Same for getImmediateReadResult, getImmediateWriteResult, etc. which
> can anyway get retrieved using Future.get().
Again, it's not the same. ImmediateResult returns current operation
state.
iofuture.get() - returns final result. Will block until result is not
ready
iofuture.getResult() - returns final result. Will not block. If final
result is not ready - null will be returned.
iofuture.getImmediateResule() - returns current operation state. Will
not block. (Could be used for debugging for example).

>
>
> The ConnectFuture doesn't add any API as well, which I found strange.
Well, it was just added, because we have ReadFuture, WriteFuture... so
the same I did for Accept and Connect I/O operations.
But again, it's possible to use plain Future.


> What do you think?
IMHO, current Grizzly implementation lets us work with Futures in
unified way. So, probably we don't need to change anything here?

Thanks.

WBR,
Alexey.
>
>
> A+
>
> -- Jeanfrancois
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>