+1
Let’s go for it.
There are some very good reasons for leaving Java 6
1. The Java 6 EOL was over a year ago (this alone is reason enough). [1]
2. Java 6 has been a security nightmare on the desktop and we shouldn’t
encourage its use anywhere. [2]
3. Java 7 has reached a critical mass. [3]
I’ve also emailed with several large Rackspace customers and gathered some
metrics too. There will be an impact to some customers but I’ve done my due
diligence and am confident we can and should move forward (I confess I’m a bit
nervous about it).
Switching to Java 7 is a HUGE backwards incompatible change and I think the
versioning must reflect that.
Here’s what I propose.
jclouds 1.7.4 (due mid-July) is the last version of jclouds to work with Java 6.
jclouds 2.0 (due early Sept.) is the first version of jclouds to work with
Java 7.
As of jclouds 2.0 we adopt the major release cadence (which we’re converging
on).
WDYT?
Everett
[1] http://www.oracle.com/technetwork/java/eol-135779.html
[2]
http://www.darkreading.com/vulnerabilities-and-threats/hackers-target-java-6-with-security-exploits/d/d-id/293?
[3] http://pages.zeroturnaround.com/Java-Tools-Technologies.html
On May 30, 2014, at 2:52 PM, Everett Toews
everett.to...@rackspace.commailto:everett.to...@rackspace.com wrote:
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.commailto: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.commailto: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.commailto: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.orgmailto: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
