jclouds-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Everett Toews <everett.to...@RACKSPACE.COM>
Subject Re: [DISCUSS] Java 6 support
Date Fri, 30 May 2014 19:52:54 GMT
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

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


[1] http://jaxenter.com/what-s-cool-in-java-these-days-50419.html

On May 30, 2014, at 1:52 AM, Ignasi Barrera <ignasi.barrera@gmail.com<mailto:ignasi.barrera@gmail.com>>

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.custine@gmail.com<mailto:chris.custine@gmail.com>>
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 Custine

On Thu, May 29, 2014 at 9:32 AM, Jeremy Daggett <jeremy.daggett@rackspace.com<mailto:jeremy.daggett@rackspace.com>>
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. ;)


On 5/28/14, 11:57 AM, "Andrew Gaul" <gaul@apache.org<mailto:gaul@apache.org>>

>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

View raw message