Moving to JDK8 involves a lot of things (1) Get Hadoop apps to be able to run on JDK8 and chose JDK8 language features. This is already possible with the decoupling of apps from the platform. (2) Get the platform to run on JDK8. This can be done so that we can run Hadoop on both JDK8 and JDK7 without any compatibility issues. This in itself is a huge move, what with potential GC behavior changes, native library compat etc. (3) Get the platform to use JDK8 language features. As much as I love the new stuff in JDK8, I'm willing to postpone usage of the language features in the platform till the time when JDK8 is already in full force.
So, how about we do (1) + (2) for now, get JDK8 going and then come around to make the decision of dropping support for JDK7? This is no different from what we did for the adoption of JDK7. For a bit of time (2/3 releases?), we were able to run on both JDK6 and JDK7 and we are phasing out JDK6 only when most of the community stopped using it. Thanks, +Vinod On Mar 2, 2015, at 8:08 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: >> Given that we already agreed to put in JDK7 in 2.7, and that the >> classpath is a fairly minor irritant given some existing solutions (e.g. a >> new default classloader), how do you quantify the benefit for users? >> >> I looked at our thread on this topic from last time, and we (meaning at > least myself and Tucu) agreed to a one-time exception to the JDK7 bump in > 2.x for practical reasons. We waited for so long that we had some assurance > JDK6 was on the outs. Multiple distros also already had bumped their min > version to JDK7. This is not true this time around. Bumping the JDK version > is hugely impactful on the end user, and my email on the earlier thread > still reflects my thoughts on JDK compatibility: > > http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201406.mbox/%3CCAGB5D2a5fEDfBApQyER_zyhc8a4Xd_ea1wJSsxxkiAiDZO9%2BNg%40mail.gmail.com%3E > >> ..... > Right now, the incompatible changes would be JDK8, classpath isolation, and > whatever is already in trunk. I can audit these existing trunk changes when > branch-3 is cut.
