hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymie Stata <rst...@altiscale.com>
Subject Re: Plans of moving towards JDK7 in trunk
Date Wed, 09 Apr 2014 02:44:40 GMT
> 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.ryza@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 <kasha@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 <eli@cloudera.com> wrote:
>>
>> > On Tue, Apr 8, 2014 at 2:00 AM, Ottenheimer, Davi
>> > <Davi.Ottenheimer@emc.com> wrote:
>> > >> From: Eli Collins [mailto:eli@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.
>> >
>>

Mime
View raw message