If you see the community discussion thread on 2.8, my proposal was to support *both* JDK 7 and JDK 8 first. The last time we had discussion about dropping JDKs it wasn’t fun, so let’s not go there for now.
In terms of runtime support for JDK 8, yes, there is vast evidence that things already work as they are in Hadoop and all the way up to dependent projects. This was already the case as early as Hadoop 2.6/2.7 if I remember correctly, so nothing new here. We should target source-level support of JDK 8 too, around which you outlined a bunch of issues around dependencies. I also found a bunch of issues around generating documentation, site etc. I propose that we track them under the umbrella JIRA and make progress there first. Thanks +Vinod > On Oct 13, 2015, at 1:17 AM, Tsuyoshi Ozawa <oz...@apache.org> wrote: > > Thank you for sharing lots information and joining discussion. > > About the runtime support of JDK-8, let's describe it on wiki. It > would be great for users to clarify which JDK version they should use. > It's also useful to describe to use "1.8.0_40 or above" explicitly. > Andrew, Elliott, could you update wiki or can I update wiki to add the > description? > > https://wiki.apache.org/hadoop/HadoopJavaVersions > > About the source code level, I summarize opinions by users and > developers as follows: > > 1. Moving trunk to the java-8 compatible dependencies. > 2. Creating branch-2-java-8 after 1. > 3. Dropping Java 7 support (maybe when we support JDK 9?) after 2. > Currently, we don't have any consensus. > >> I'd be +1 for moving trunk to the java-8 compatible dependencies, and to >> have the jenkins nighly builds only before java 8; we'd still have the patch >> and branch-2 runs on Java 7. That way, people will only have one nightly >> mail from Jenkins saying the build is broken, and maybe pay more attention >> to the fact. > > This way looks good to me. > Steve, do you know how to do this? In fact, I don't know so much about > how to change and update nightly builds. Should we contact to Yetus > community or Apache Infra team? > > Best, > - Tsuyoshi > > > > On Sat, Oct 10, 2015 at 7:17 AM, Sangjin Lee <sj...@apache.org> wrote: >> Yes, at least for us, dropping the java 7 support (e.g. moving to java 8 >> source-wise) **at this point** would be an issue. I concur with the >> sentiment that we should preserve the java 7 support on branch-2 (not not >> move to java 8 source level) but can consider it for trunk. My 2 cents. >> >> Thanks, >> Sangjin >> >> On Fri, Oct 9, 2015 at 10:43 AM, Steve Loughran <ste...@hortonworks.com> >> wrote: >> >>> >>>> On 7 Oct 2015, at 22:39, Elliott Clark <ecl...@apache.org> wrote: >>>> >>>> On Mon, Oct 5, 2015 at 5:35 PM, Tsuyoshi Ozawa <oz...@apache.org> wrote: >>>> >>>>> Do you have any concern about this? I’ve not >>>>> tested with HBase yet. >>>>> >>>> >>>> We've been running JDK 8u60 in production with Hadoop 2.6.X and HBase for >>>> quite a while. Everything has been very stable for us. We're running and >>>> compiling with jdk8. >>>> >>>> We had to turn off yarn.nodemanager.vmem-check-enabled. Otherwise mr jobs >>>> didn't do too well. >>>> >>> >>> maybe related to the initial memory requirements being higher? >>> >>> otherwise: did you file a JIRA? >>> >>> >>>> I'd be +1 on dropping jdk7 support. However as downstream developer it >>>> would be very weird for that to happen on anything but a major release. >>> >>> >>> Past discussion (including a big contrib from twitter) was that breaking >>> Java 7 support breaks all client apps too, which is not something people >>> were ready for. >>> >>> I'd be +1 for moving trunk to the java-8 compatible dependencies, and to >>> have the jenkins nighly builds only before java 8; we'd still have the >>> patch and branch-2 runs on Java 7. That way, people will only have one >>> nightly mail from Jenkins saying the build is broken, and maybe pay more >>> attention to the fact. >
