Le 7/16/13 12:10 PM, sebb a écrit : >>> I don't think that's generally true. >>> >> If MINA is part of a larger system, then updating Java as well as MINA >>> >> is a lot more work and testing than just updating MINA. >>> >> Especially if the system is installed on multiple nodes which may have >>> >> different hardware and configs. >> > >> > Those objections are very valuable for MINA 2. MINA 3 will take at least >> > one more year to get out in a RC state, so I would rather not spend a >> > minute of my very busy agenda to take care of Java 6 compatibility for >> > MINA 3. >> > I don't want to see MINA to face the same problem that >> > commons-collection is facing : 9 years after the addition of generics in >> > Java, we still don't have a library supporting them... > That's an entirely separate issue; part of the problem is it's > extremely difficult to do generics correctly in libraries such as > collections. In fact, it's not at all a separate issue : just because it's really difficult to do it correctly does not mean you don't have to do it. The big difference is the time you have to complete the work. I can understand that it took 9 years for some team working 1h a week on a project to move to generic, but it's not something we want to get stuck into : by getting rid of tme constraints (ie, removing the need to keep a compatibility with an already EOL version of Java), we spare this previous time delivering some package in a (soemhow) better timing, not leaving our users with the alternative of using a semi-OSS component like guava.
In other words, "Time is of the essence" -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
