hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tsuyoshi OZAWA <ozawa.tsuyo...@gmail.com>
Subject Re: Plans of moving towards JDK7 in trunk
Date Sun, 13 Apr 2014 09:09:25 GMT
Hi,

+1 for Karthik's idea(non-binding).

IMO, we should keep the compatibility between JDK 6 and JDK 7 on both branch-1
and branch-2, because users can be using them. For future releases that we can
declare breaking compatibility(e.g. 3.0.0 release), we can use JDK 7
features if we
can get benefits. However, it can increase maintenance costs and distributes the
efforts of contributions to maintain branches. Then, I think it is
reasonable approach
that we use limited and minimum JDK-7 APIs when we have reasons we need to use
the features.
By the way, if we start to use JDK 7 APIs, we should declare the basis
when to use
JDK 7 APIs on Wiki not to confuse contributors.

Thanks,
- Tsuyoshi

On Wed, Apr 9, 2014 at 11:44 AM, Raymie Stata <rstata@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.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.
>>> >
>>>



-- 
- Tsuyoshi

Mime
View raw message