So, although consider my opinion of 'low impact', I agree with Peter that there need to be a substantial case for platform-like code to abandon a previous Java version. IMHO, Java 5 has a LOT of features that most platforms can leverage to their advantage, Java 6 much less so...
My primary project just recently up'ed the requirement to Java 6, due to a nasty bug in the Generics compiler in Java 5, for which there is never going to be a fix. If/when there are such issues in River, then sure... As for 'recommended version', it is quite important that River's core team and test set up are using JDK 1.5 in their toolkits, as it otherwise quickly 'leaks' 1.6 methods into the codebase. Also, if the test or build tools require 1.6, then I think that is totally acceptable as well. Cheers and keep up the good momentum.... Cheers Niclas On Tue, Feb 8, 2011 at 2:47 PM, Peter Firmstone <j...@zeus.net.au> wrote: > -1 Peter Firmstone. > > I could vote +1 to dropping support (us fixing something to work around a > Java 5 only bug) due to the resources of our small team, leaving the door > open to the community to contribute patches, but not compatibility I'm > afraid, I just haven't seen a good reason why we need to make River > incompatible with Java 5. > > Is there a feature we need in the platform that requires Java 6? > > Are we adding a feature to a proxy that requires Java 6? > > I don't think a service implementation (server side) is a good enough reason > to drop compatibility. > > That doesn't mean that we can't produce a service implementation that does > require Java 6 as a minimum and release it as a separate concern, just that > it's unreasonable to expect everything else to be dragged along with it. > > Note: The QA Test suite requires JDK1.6 to compile, because some of it's > tests depend on internal Sun Java platform implementation details. The QA > harness is compatible with earlier versions of Java. The jtreg tests > require Java 5, due to some tests relying on internal Sun Java platform > implementation details. > > I recommend people use Java 6 if they can, but not everyone is that lucky. > > I understand the reasons for making such decisions, but I think we need to > further investigate breaking the codebase up into smaller easier to maintain > components, then determining the requirements of each before decisions like > this are made. We have too much coupling between implementation and > platform at present. > > Peter. > > > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug
