After reading this thread and thinking a bit about it, I think it should be
OK such move up to JDK7 in Hadoop 2 for the following reasons:
* Existing Hadoop 2 releases and related projects are running
on JDK7 in production.
* Commercial vendors of Hadoop have already done lot of
work to ensure Hadoop on JDK7 works while keeping Hadoop
on JDK6 working.
* Different from many of the 3rd party libraries used by Hadoop,
JDK is much stricter on backwards compatibility.
IMPORTANT: I take this as an exception and not as a carte blanche for 3rd
party dependencies and for moving from JDK7 to JDK8 (though it could OK for
the later if we end up in the same state of affairs)
Even for Hadoop 2.5, I think we could do the move:
* Create the Hadoop 2.5 release branch.
* Have one nightly Jenkins job that builds Hadoop 2.5 branch
with JDK6 to ensure not JDK7 language/API feature creeps
out in Hadoop 2.5. Keep this for all Hadoop 2.5.x releases.
* Sanity tests for the Hadoop 2.5.x releases should be done
with JDK7.
* Apply Steve’s patch to require JDK7 on trunk and branch-2.
* Move all Apache Jenkins jobs to build/test using JDK7.
* Starting from Hadoop 2.6 we support JDK7 language/API
features.
Effectively what we are ensuring that Hadoop 2.5.x builds and test with
JDK6 & JDK7 and that all tests towards the release
are done with JDK7.
Users can proactively upgrade to JDK7 before upgrading to Hadoop 2.5.x, or
if upgrade to Hadoop 2.5.x and they run into any issue because of JDK6
(which it would be quite unlikely) they can reactively upgrade to JDK7.
Thoughts?
On Tue, Jun 24, 2014 at 4:22 PM, Andrew Wang <andrew.w...@cloudera.com>
wrote:
Hi all,
On dependencies, we've bumped library versions when we think it's safe
and
the APIs in the new version are compatible. Or, it's not leaked to the
app
classpath (e.g the JUnit version bump). I think the JIRAs Arun mentioned
fall into one of those categories. Steve can do a better job explaining
this to me, but we haven't bumped things like Jetty or Guava because they
are on the classpath and are not compatible. There is this line in the
compat guidelines:
- Existing MapReduce, YARN & HDFS applications and frameworks should
work unmodified within a major release i.e. Apache Hadoop ABI is
supported.
Since Hadoop apps can and do depend on the Hadoop classpath, the
classpath
is effectively part of our API. I'm sure there are user apps out there
that
will break if we make incompatible changes to the classpath. I haven't
read
up on the MR JIRA Arun mentioned, but there MR isn't the only YARN app
out
there.
Sticking to the theme of "work unmodified", let's think about the user
effort required to upgrade their JDK. This can be a very expensive task.
It
might need approval up and down the org, meaning lots of certification,
testing, and signoff. Considering the amount of user effort involved
here,
it really seems like dropping a JDK is something that should only happen
in
a major release. Else, there's the potential for nasty surprises in a
supposedly "minor" release.
That said, we are in an unhappy place right now regarding JDK6, and it's
true that almost everyone's moved off of JDK6 at this point. So, I'd be
okay with an intermediate 2.x release that drops JDK6 support (but no
incompatible changes to the classpath like Guava). This is basically
free,
and we could start using JDK7 idioms like multi-catch and new NIO stuff
in
Hadoop code (a minor draw I guess).
My higher-level goal though is to avoid going through this same pain
again
when JDK7 goes EOL. I'd like to do a JDK8-based release before then for
this reason. This is why I suggested skipping an intermediate 2.x+JDK7
release and leapfrogging to 3.0+JDK8. 10 months is really not that far in
the future, and it seems like a better place to focus our efforts. I was
also hoping it'd be realistic to fix our classpath leakage by then, since
then we'd have a nice, tight, future-proofed new major release.
Thanks,
Andrew
On Tue, Jun 24, 2014 at 11:43 AM, Arun C Murthy <a...@hortonworks.com>
wrote:
Andrew,
Thanks for starting this thread. I'll edit the wiki to provide more
context around rolling-upgrades etc. which, as I pointed out in the
original thread, are key IMHO.
On Jun 24, 2014, at 11:17 AM, Andrew Wang <andrew.w...@cloudera.com>
wrote:
https://wiki.apache.org/hadoop/MovingToJdk7and8
I think based on our current compatibility guidelines, Proposal A is
the
most attractive. We're pretty hamstrung by the requirement to keep
the
classpath the same, which would be solved by either OSGI or shading
our
deps (but that's a different discussion).
I don't see that anywhere in our current compatibility guidelines.
As you can see from
http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/Compatibility.html
we do not have such a policy (pasted here for convenience):
Java Classpath
User applications built against Hadoop might add all Hadoop jars
(including Hadoop's library dependencies) to the application's
classpath.
Adding new dependencies or updating the version of existing
dependencies
may interfere with those in applications' classpaths.
Policy
Currently, there is NO policy on when Hadoop's dependencies can change.
Furthermore, we have *already* changed our classpath in hadoop-2.x.
Again,
as I pointed out in the previous thread, here is the precedent:
On Jun 21, 2014, at 5:59 PM, Arun C Murthy <a...@hortonworks.com>
wrote:
Also, this is something we already have done i.e. we updated some of
our
software deps in hadoop-2.4 v/s hadoop-2.2 - clearly not something as
dramatic as JDK. Here are some examples:
https://issues.apache.org/jira/browse/HADOOP-9991
https://issues.apache.org/jira/browse/HADOOP-10102
https://issues.apache.org/jira/browse/HADOOP-10103
https://issues.apache.org/jira/browse/HADOOP-10104
https://issues.apache.org/jira/browse/HADOOP-10503
thanks,
Arun
--
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.
--
Alejandro
