dev@grizzly.java.net

Re: Should notificationObject be Instance of Future in Grizzly 2.0?

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Tue, 16 Jun 2009 14:50:50 +0200

Hi Ming,

good catch, this class was moved from 1.9.x branch, and for sure could
be improved by using Future and CompletionHandler abstractions instead
of Callable, Runnable etc.
Please file the issue, I'll get to it asap, or any patch from your
side will be also very appreciated :)

Thank you.

WBR,
Alexey.

On Jun 15, 2009, at 23:31 , ming qin wrote:

>
> Grizzly 2.0 framework( grizzly-framework) API is based on
> java.util.concurrent.Future. In release 2.0.0-M3, only one class
> ( com.sun.grizzly.utils.conditions.DefaultConditionListener) is
> referring java.util.concurrent.Callable( another is Junit test
> class- AsyncWriteQueueTest.java).
>
> Since there are no other classes referring Callable except
> DefaultConditionListener itself in whole grizzly-framework API,
> doesn't nofiyListernObject method need care about noticationObject
> as instance of Callable?
>
> Below is notifyListenerObject method,
> public static final void notifyListenerObject(Object
> notificationObject) {
> if (notificationObject instanceof CountDownLatch) {
> ….
> } else if (notificationObject instanceof Callable) {
> …….
> }
> } else if (notificationObject instanceof Runnable) {
> ………
> } else {
> synchronized (notificationObject) {
> notificationObject.notify();
> }
> }
> }
>
> Ming Qin
> Cell Phone 858-353-2839
>
>