Hi *, I am in the situation where 1.6 would be preferred (and that's why I expressed my positive feeling on switching to JDK6): for Digester 3 I had to revert the initial import of the Annotations Processor, because still using Java5 com.sun.* APT APIs - not present at least in our Continuum JVM - but if switching to Java6 to use javax APIs, older users that didn't update their JVMs, could not get benefits from eventual bufixes.
Any suggestion? TIA!!! all the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Feb 10, 2012 at 5:20 PM, sebb <seb...@gmail.com> wrote: > On 10 February 2012 15:18, Mark Thomas <ma...@apache.org> wrote: >> On 10/02/2012 14:41, Ralph Goers wrote: >>> In many cases the differences between Java 5 and 6 aren't noticeable. >>> If the project doesn't require anything from Java 6, why require it? >>> I'm sure there are quite a few places where it is still being used >>> despite the end of support. >> >> I think there are several reasons: >> - It strikes me as odd to release a new version of a component - such as >> pool2 - targeting a version of the JVM that is already effectively obsolete. > > So are you saying that if we release a new version of commons-logging > it should require Java 1.6? > That would be completely unnecessary. > >> - There are some platforms (I am thinking primarily of OSX) where >> getting ones hands on a Java 5 implementation requires a fair amount of >> jumping through hoops. [1] > > But surely Eclipse can be told to target Java 1.5 ? That would at > least deal with the compiler warnings. > >> - Pool2 feeds dbcp2 and Java6 includes JDBC4 which is not backwards >> compatible with JDBC3. DBCP is already jumping through hoops with >> 1.3/1.4 and targeting Java6 makes DBCP easier > > I don't see how problems with JDBC are relevant to Pool. > >> - Something we have seen in Tomcat is JVM bugs not being fixed in older >> releases. The fewer older JVM versions we target, the less likely we are >> to hit these sorts of bugs. Granted, I haven't seen any of this in >> Commons. Yet. > >> Some of these arguments are pool2 specific but overall, my preference is >> for targeting the lowest currently supported version of the JVM unless >> there is a compelling argument not to. > > Java 1.5 *is* still supported. > >> Mark >> >> >> [1] I happened to be using my Mac to work on pool 2 and noticed a whole >> bunch of @Override warnings because my Mac doesn't have a Java 5 (mainly >> because after the latest OS upgrade I couldn't be bothered to jump >> through the hoops yet again(, >> >> >>> >>> In short, if the project needs features found only in Java 6 then >>> make it the minimum, otherwise support Java 5. >>> >>> Ralph >>> >>> Sent from my iPad >>> >>> On Feb 10, 2012, at 5:51 AM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >>>> Hi All, >>>> >>>> [pool2] just went from Java 5 to Java 6 because Java 5 requires >>>> paid-for support from Oracle. >>>> >>>> How does the ML feel about moving projects that are now on Java 5 >>>> to Java 6? >>>> >>>> Thank you, Gary >>>> >>>> -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in >>>> Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring >>>> Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK >>>> Blog: http://garygregory.wordpress.com Home: >>>> http://garygregory.com/ Tweet! http://twitter.com/GaryGregory >>> >>> --------------------------------------------------------------------- >>> >>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org