First off, I’m totally on board with the move to Java 7. Beyond Java 6 being EOL, Java 7 has finally reached some kind of critical mass [1].
My primary concern is around the kind of change it is and the timing of it. This is a major backwards incompatible change. As soon as we write that first line of code using a Java 7 feature, we’re leaving a lot of people behind. If 1.8 is our next release after 1.7.3 then dropping support for it seems a bit sudden for our users (both Rackspace and jclouds in general). However, I’m not entirely certain of that. I would prefer this to be a data-driven decision and I need some time to dig into the data. Please give me until the end of June to gather some data and poll our customers. I also think we should be prepared to support the last version of jclouds with Java 6 longer than our usual support (i.e. an exception to our N-1 policy). This is especially important for security issues. I’m sure we have users from all across the jclouds community that will not be able to upgrade from Java 6 for X amount of time for Y reason. We can’t abandon these developers. Everett [1] http://jaxenter.com/what-s-cool-in-java-these-days-50419.html On May 30, 2014, at 1:52 AM, Ignasi Barrera <ignasi.barr...@gmail.com<mailto:ignasi.barr...@gmail.com>> wrote: Totally agree with Jeremy and Chris. I think it is reasonable to think that users that don't want to upgrade the JVM won't want to upgrade to the latest jclouds version (major changes, newest Guava and other deps, etc). Keeping 1.7 compatible with 1.6 and dropping support for it in 1.8 sounds like a reasonable way to move forward. El 30/05/2014 00:46, "Chris Custine" <chris.cust...@gmail.com<mailto:chris.cust...@gmail.com>> escribió: I agree with Jeremy, in that 1.8 seems like a reasonable point to start requiring Java 7 as a minimum. I know many people are still using jclouds 1.6.x and Java 6 so I don't think you will cause too much grief for anyone moving up to the eventual jclouds 1.8 release (meaning, they are likely to stay at jclouds 1.6 or 1.7 for quite some time anyway). Just my 2 cents. Chris -- Chris Custine On Thu, May 29, 2014 at 9:32 AM, Jeremy Daggett <jeremy.dagg...@rackspace.com<mailto:jeremy.dagg...@rackspace.com>> wrote: I really appreciate that you brought this up Andrew! I have been through every Java version transition since v1.0. I know the challenges and pain points this decision might cause some developers. It will most likely be an issue in enterprise environments where Java runtimes can only change every couple of years. Technology changes. Java 6 is no longer supported. That alone should be the deciding factor for the project. In my experience, the industry best practice is to support the most current version and one previous. I actually really like what vert.x did in requiring a Java 7 (or newer) right from the start. Here is an idea for a potential transition plan: jclouds 1.7.x -> Java 6+ (maintenance branch to support Java 6+) jclouds 1.8.x -> Java 7+ In order to move jclouds forward, we need to drop support for Java 6. If it were totally up to me, I would vote to jump right to Java 8, but that is just my perspective. ;) /jd On 5/28/14, 11:57 AM, "Andrew Gaul" <g...@apache.org<mailto:g...@apache.org>> wrote: >jclouds presently supports Java 6, 7, and 8 which imposes extra >development costs and prevents uptake of new language and library >features including try-with-resources, NIO.2, and HTTP client >improvements. Oracle ceased public updates to Java 6 in early 2013[1] >and jclouds could use this to guide its support strategy. The jclouds >developers would like to understand how many users continue to use Java >6 and what prevents upgrading to newer versions. Please respond to this >thread with any relevant information. Thanks! > >-- >Andrew Gaul >http://gaul.org/
