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 <[email protected]> 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 <[email protected]> > wrote: > >> >> > On 7 Oct 2015, at 22:39, Elliott Clark <[email protected]> wrote: >> > >> > On Mon, Oct 5, 2015 at 5:35 PM, Tsuyoshi Ozawa <[email protected]> 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.
