You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Jeff MAURY <je...@jeffmaury.com> on 2014/11/06 23:15:01 UTC
Review DIRMINA-994
Hello,
upon Emmanuel's request, I reviewed the fix for DIRMINA-994
(commit f1972fc3de8c4074ff7b60f8c557d3c53013e30b). Here are my remarks:
- the Future framework in MINA2 is not linked in any form to JDK's
Future, is there any reason for that ? I've seen that IOFuture in MINA3
extends Future
- Regarding MINA3, I suggest that IOFuture's implementation should
benefit from helper class AbstractQueuedSynchronizer (
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/AbstractQueuedSynchronizer.html).
As MINA3 Future framework is linked to the JDK Future framework, the change
should be quite small and simple. I will open a JIRA for that
Jeff
Re: Review DIRMINA-994
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 07/11/14 12:06, Jeff MAURY a écrit :
> Le Fri Nov 07 2014 at 07:57:09, Emmanuel Lécharny <el...@gmail.com> a
> écrit :
>
>
>> I'm just stating the fact that when future were introduced, we weren't
>> using generic yet, because we wanted to keep the 1.4 compatibility. When
>> we decided to switch to Java 5, we added generic, but kept Future.
>>
>> I'm not saying it was a smart move, this is just what happened. In
>> retrospect, that was lazy.
>>
>> Keep in mind that MINA history is nearly 10 years old...
>>
> The purpose of my questions was indeed to try to get some historic info as
> I'm quite new to MINA
Well, the JIRA in which the Futures were discussed is
https://issues.apache.org/jira/browse/DIRMINA-39. 9 years old ;-)
back then, it was inspired by Java 5 Future, but the decision to switch
away from Java 1.4 was taken in late 2006. Although the IoFuture classes
weren't removed...
Hope it helps !
Re: Review DIRMINA-994
Posted by Jeff MAURY <je...@jeffmaury.com>.
Le Fri Nov 07 2014 at 07:57:09, Emmanuel Lécharny <el...@gmail.com> a
écrit :
> Le 07/11/14 07:30, Jeff MAURY a écrit :
> > Le Fri Nov 07 2014 at 1:42:43 AM, Emmanuel Lécharny <el...@gmail.com>
> a
> > écrit :
> >
> >> Le 06/11/14 23:15, Jeff MAURY a écrit :
> >>> Hello,
> >>>
> >>> upon Emmanuel's request, I reviewed the fix for DIRMINA-994
> >>> (commit f1972fc3de8c4074ff7b60f8c557d3c53013e30b). Here are my
> remarks:
> >>>
> >>> - the Future framework in MINA2 is not linked in any form to JDK's
> >>> Future, is there any reason for that ? I've seen that IOFuture in
> >> MINA3
> >>> extends Future
> >> Java Future were introduced in hava 5. MINA was created with Java 1.4
> >> compatibility as a target.
> >>
> > Can't accpet it, as MINA2 code uses generics.
>
> I'm just stating the fact that when future were introduced, we weren't
> using generic yet, because we wanted to keep the 1.4 compatibility. When
> we decided to switch to Java 5, we added generic, but kept Future.
>
> I'm not saying it was a smart move, this is just what happened. In
> retrospect, that was lazy.
>
> Keep in mind that MINA history is nearly 10 years old...
>
The purpose of my questions was indeed to try to get some historic info as
I'm quite new to MINA
Jeff
Re: Review DIRMINA-994
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 07/11/14 07:30, Jeff MAURY a écrit :
> Le Fri Nov 07 2014 at 1:42:43 AM, Emmanuel Lécharny <el...@gmail.com> a
> écrit :
>
>> Le 06/11/14 23:15, Jeff MAURY a écrit :
>>> Hello,
>>>
>>> upon Emmanuel's request, I reviewed the fix for DIRMINA-994
>>> (commit f1972fc3de8c4074ff7b60f8c557d3c53013e30b). Here are my remarks:
>>>
>>> - the Future framework in MINA2 is not linked in any form to JDK's
>>> Future, is there any reason for that ? I've seen that IOFuture in
>> MINA3
>>> extends Future
>> Java Future were introduced in hava 5. MINA was created with Java 1.4
>> compatibility as a target.
>>
> Can't accpet it, as MINA2 code uses generics.
I'm just stating the fact that when future were introduced, we weren't
using generic yet, because we wanted to keep the 1.4 compatibility. When
we decided to switch to Java 5, we added generic, but kept Future.
I'm not saying it was a smart move, this is just what happened. In
retrospect, that was lazy.
Keep in mind that MINA history is nearly 10 years old...
Re: Review DIRMINA-994
Posted by Jeff MAURY <je...@jeffmaury.com>.
Le Fri Nov 07 2014 at 1:42:43 AM, Emmanuel Lécharny <el...@gmail.com> a
écrit :
> Le 06/11/14 23:15, Jeff MAURY a écrit :
> > Hello,
> >
> > upon Emmanuel's request, I reviewed the fix for DIRMINA-994
> > (commit f1972fc3de8c4074ff7b60f8c557d3c53013e30b). Here are my remarks:
> >
> > - the Future framework in MINA2 is not linked in any form to JDK's
> > Future, is there any reason for that ? I've seen that IOFuture in
> MINA3
> > extends Future
>
> Java Future were introduced in hava 5. MINA was created with Java 1.4
> compatibility as a target.
>
Can't accpet it, as MINA2 code uses generics.
>
> > - Regarding MINA3, I suggest that IOFuture's implementation should
> > benefit from helper class AbstractQueuedSynchronizer (
> > http://docs.oracle.com/javase/1.5.0/docs/api/java/util/
> concurrent/locks/AbstractQueuedSynchronizer.html).
> > As MINA3 Future framework is linked to the JDK Future framework, the
> change
> > should be quite small and simple. I will open a JIRA for that
>
> Ok.
>
> Thanks !
>
>
Re: Review DIRMINA-994
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 06/11/14 23:15, Jeff MAURY a écrit :
> Hello,
>
> upon Emmanuel's request, I reviewed the fix for DIRMINA-994
> (commit f1972fc3de8c4074ff7b60f8c557d3c53013e30b). Here are my remarks:
>
> - the Future framework in MINA2 is not linked in any form to JDK's
> Future, is there any reason for that ? I've seen that IOFuture in MINA3
> extends Future
Java Future were introduced in hava 5. MINA was created with Java 1.4
compatibility as a target.
> - Regarding MINA3, I suggest that IOFuture's implementation should
> benefit from helper class AbstractQueuedSynchronizer (
> http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/AbstractQueuedSynchronizer.html).
> As MINA3 Future framework is linked to the JDK Future framework, the change
> should be quite small and simple. I will open a JIRA for that
Ok.
Thanks !