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.
