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" <[email protected]> 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/
