Just to echo Steve's idea -- if we're seriously considering supporting JDK 8, maybe the first thing to do is to set up the jenkins to run with JDK 8? I'm happy to help. Does anyone know who I can talk to if I need to play around with all the Jenkins knob?
~Haohui On Tue, Oct 13, 2015 at 8:24 AM, Vinod Vavilapalli <vino...@hortonworks.com> wrote: > 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. >> >
