Salut,
Oleksiy Stashok wrote:
> 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();
Yes, but take a look at AIO:
http://openjdk.java.net/projects/nio/javadoc/java/nio/channels/AsynchronousSocketChannel.html
They do the same thing with a unified API :-) I would like us to do the
same.
>
> 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 as get(0,TimeUnits.SECONDS);
> V get(long timeout,
> TimeUnit unit)
We should re-use that one instead.
>
>> 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.
What does it means exactly? If I'm doing a read, what will I get?
Will
> not block. (Could be used for debugging for example).
Hum...Do you have an example where it can be used in real? I'm not
convinced about "debugging purpose". I'm really not toward those API
right now unless we have a strong use case :-)
>
>>
>>
>> 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?
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...
A+
-- Jeanfrancois
>
> Thanks.
>
> WBR,
> Alexey.
>>
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>> <mailto:dev-help_at_grizzly.dev.java.net>
>>
>