> It might make sense to try to enumerate the benefits of switching to > Java7 APIs and dependencies.
- Java7 introduced a huge number of language, byte-code, API, and tooling enhancements! Just to name a few: try-with-resources, newer and stronger encyrption methods, more scalable concurrency primitives. See http://www.slideshare.net/boulderjug/55-things-in-java-7 - We can't update current dependencies, and we can't add cool new ones. - Putting language/APIs aside, don't forget that a huge amount of effort goes into qualifying for Java6 (at least, I hope the folks claiming to support Java6 are putting in such an effort :-). Wouldn't Hadoop users/customers be better served if qualification effort went into Java7/8 versus Java6/7? Getting to Java7 as a development env (and Java8 as a runtime env) seems like a no-brainer. Question is: How? On Tue, Apr 8, 2014 at 10:21 AM, Sandy Ryza <sandy.r...@cloudera.com> wrote: > It might make sense to try to enumerate the benefits of switching to Java7 > APIs and dependencies. IMO, the ones listed so far on this thread don't > make a compelling enough case to drop Java6 in branch-2 on any time frame, > even if this means supporting Java6 through 2015. For example, the change > in RawLocalFileSystem semantics might be an incompatible change for > branch-2 any way. > > > On Tue, Apr 8, 2014 at 10:05 AM, Karthik Kambatla <ka...@cloudera.com>wrote: > >> +1 to NOT breaking compatibility in branch-2. >> >> I think it is reasonable to require JDK7 for trunk, if we limit use of >> JDK7-only API to security fixes etc. If we make other optimizations (like >> IO), it would be a pain to backport things to branch-2. I guess this all >> depends on when we see ourselves shipping Hadoop-3. Any ideas on that? >> >> >> On Tue, Apr 8, 2014 at 9:19 AM, Eli Collins <e...@cloudera.com> wrote: >> >> > On Tue, Apr 8, 2014 at 2:00 AM, Ottenheimer, Davi >> > <davi.ottenhei...@emc.com> wrote: >> > >> From: Eli Collins [mailto:e...@cloudera.com] >> > >> Sent: Monday, April 07, 2014 11:54 AM >> > >> >> > >> >> > >> IMO we should not drop support for Java 6 in a minor update of a >> stable >> > >> release (v2). I don't think the larger Hadoop user base would find it >> > >> acceptable that upgrading to a minor update caused their systems to >> stop >> > >> working because they didn't upgrade Java. There are people still >> getting >> > >> support for Java 6. ... >> > >> >> > >> Thanks, >> > >> Eli >> > > >> > > Hi Eli, >> > > >> > > Technically you are correct those with extended support get critical >> > security fixes for 6 until the end of 2016. I am curious whether many of >> > those are in the Hadoop user base. Do you know? My guess is the vast >> > majority are within Oracle's official public end of life, which was over >> 12 >> > months ago. Even Premier support ended Dec 2013: >> > > >> > > http://www.oracle.com/technetwork/java/eol-135779.html >> > > >> > > The end of Java 6 support carries much risk. It has to be considered in >> > terms of serious security vulnerabilities such as CVE-2013-2465 with CVSS >> > score 10.0. >> > > >> > > http://www.cvedetails.com/cve/CVE-2013-2465/ >> > > >> > > Since you mentioned "caused systems to stop" as an example of what >> would >> > be a concern to Hadoop users, please note the CVE-2013-2465 availability >> > impact: >> > > >> > > "Complete (There is a total shutdown of the affected resource. The >> > attacker can render the resource completely unavailable.)" >> > > >> > > This vulnerability was patched in Java 6 Update 51, but post end of >> > life. Apple pushed out the update specifically because of this >> > vulnerability (http://support.apple.com/kb/HT5717) as did some other >> > vendors privately, but for the majority of people using Java 6 means they >> > have a ticking time bomb. >> > > >> > > Allowing it to stay should be considered in terms of accepting the >> whole >> > risk posture. >> > > >> > >> > There are some who get extended support, but I suspect many just have >> > a if-it's-not-broke mentality when it comes to production deployments. >> > The current code supports both java6 and java7 and so allows these >> > people to remain compatible, while enabling others to upgrade to the >> > java7 runtime. This seems like the right compromise for a stable >> > release series. Again, absolutely makes sense for trunk (ie v3) to >> > require java7 or greater. >> > >>
