hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: Plans of moving towards JDK7 in trunk
Date Thu, 10 Apr 2014 17:04:21 GMT
On Thu, Apr 10, 2014 at 1:11 AM, Steve Loughran <stevel@hortonworks.com>wrote:

> On 9 April 2014 23:52, Eli Collins <eli@cloudera.com> wrote:
>
> >
> >
> > For the sake of this discussion we should separate the runtime from
> > the programming APIs. Users are already migrating to the java7 runtime
> > for most of the reasons listed below (support, performance, bugs,
> > etc), and the various distributions cert their Hadoop 2 based
> > distributions on java7.  This gives users many of the benefits of
> > java7, without forcing users off java6. Ie Hadoop does not need to
> > switch to the java7 programming APIs to make sure everyone has a
> > supported runtime.
> >
> >
> +1: you can use Java 7 today; I'm not sure how tested Java 8 is
>
>
> > The question here is really about when Hadoop, and the Hadoop
> > ecosystem (since adjacent projects often end up in the same classpath)
> > start using the java7 programming APIs and therefore break
> > compatibility with java6 runtimes. I think our java6 runtime users
> > would consider dropping support for their java runtime in an update of
> > a major release to be an incompatible change (the binaries stop
> > working on their current jvm).
>
>
> do you mean major 2.x -> 3.y or minor 2.x -> 2.(x+1)  here?
>

I mean 2.x --> 2.(x+1).  Ie I'm running the 2.4 stable and upgrading to 2.5.


>
>
> > That may be worth it if we can
> > articulate sufficient value to offset the cost (they have to upgrade
> > their environment, might make rolling upgrades stop working, etc), but
> > I've not yet heard an argument that articulates the value relative to
> > the cost.  Eg upgrading to the java7 APIs allows us to pull in
> > dependencies with new major versions, but only if those dependencies
> > don't break compatibility (which is likely given that our classpaths
> > aren't so isolated), and, realistically, only if the entire Hadoop
> > stack moves to java7 as well
>
>
>
>
> > (eg we have to recompile HBase to
> > generate v1.7 binaries even if they stick on API v1.6). I'm not aware
> > of a feature, bug etc that really motivates this.
> >
> > I don't see that being needed unless we move up to new java7+ only
> libraries and HBase needs to track this.
>
>  The big "recompile to work" issue is google guava, which is troublesome
> enough I'd be tempted to say "can we drop it entirely"
>
>
>
> > An alternate approach is to keep the current stable release series
> > (v2.x) as is, and start using new APIs in trunk (for v3). This will be
> > a major upgrade for Hadoop and therefore an incompatible change like
> > this is to be expected (it would be great if this came with additional
> > changes to better isolate classpaths and dependencies from each
> > other). It allows us to continue to support multiple types of users
> > with different branches, vs forcing all users onto a new version. It
> > of course means that 2.x users will not get the benefits of the new
> > API, but its unclear what those benefits are given theIy can already
> > get the benefits of adopting the newer java runtimes today.
> >
> >
> >
> I'm (personally) +1 to this, I also think we should plan to do the switch
> some time this year to not only get the benefits, but discover the costs
>


Agree



> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message