A Java 8 runtime would also offer transparent performance improvements like a reimplementation of ConcurrentSkipListMap, C2 support for AES cipher acceleration with native CPU instructions, perf improvements for going from String to byte[] or vice versa, and IIRC after 8u20 monitor lock elision using restricted transactional memory with hardware support (if available). Getting away from fully transparent changes but tractable to deal with using reflection, removal of the permanent generation, support for AEAD cipher modes like AES-GCM, stronger cipher and key exchange algorithms, TLS 1.2, support for some krb 5 features not handled previously.
On Tue, Apr 8, 2014 at 7:44 PM, Raymie Stata <rst...@altiscale.com> wrote: > > 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. > >> > > >> > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
