I agree with dropping JDK 7 support and 2.0 would be a good flag to users. I opened a pull request to require Java 7 and give us some tangible benefit, > 2 GB single-part payloads[1]. We should allow the possibility of further 1.7.x releases but not commit to a schedule. Waiting until September for 2.0 to address our Guava 16 incompatibility seems like a long time given the increasing number of users encountering this issue. Can we continue the release schedule discussion as a separate thread on jclouds-dev since we should drive the release date based on which features scope into a convenient time-frame?
[1] https://github.com/jclouds/jclouds/pull/426 On Mon, Jun 30, 2014 at 08:12:18PM +0000, Everett Toews wrote: > +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/1111293? > [3] http://pages.zeroturnaround.com/Java-Tools-Technologies.html > > > On May 30, 2014, at 2:52 PM, Everett Toews > <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> 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" > <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[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/ > > > > -- Andrew Gaul http://gaul.org/
