Following up on ecosystem, I just took a look at the Apache trunk pom.xml
files for HBase, Flume and Oozie. All are specifying 1.6 for source and
target in the maven-compiler-plugin configuration, so there may be
additional follow-up required here. (For example, if HBase has made a
statement
Guava is a separate problem and I think we should have a separate
discussion what can we do about guava? That's more traumatic than a JDK
update, I fear, as the guava releases care a lot less about compatibility.
I don't worry about JDK updates removing classes like StringBuffer
because
Hi all, responding to multiple messages here,
Arun, thanks for the clarification regarding MR classpaths. It sounds like
the story there is improved and still improving.
However, I think we still suffer from this at least on the HDFS side. We
have a single JAR for all of HDFS, and our clients
As someone else already mentioned, we should announce one future release
(may be, 2.5) as the last JDK6-based release before making the move to JDK7.
I am comfortable calling 2.5 the last JDK6 release.
On Fri, Jun 27, 2014 at 11:26 AM, Andrew Wang andrew.w...@cloudera.com
wrote:
Hi all,
FYI I also just updated the wiki page with a Proposal D, aka Tucu plan,
which I think is essentially Proposal C but tabling JDK8 plans for now.
https://wiki.apache.org/hadoop/MovingToJdk7and8
Karthik, thanks for ringing in re: 2.5. I guess there's nothing urgently
required, the Jenkins stuff
Thanks everyone for the discussion. Looks like we have come to a pragmatic and
progressive conclusion.
In terms of execution of the consensus plan, I think a little bit of caution is
in order.
Let's give downstream projects more of a runway.
I propose we inform HBase, Pig, Hive etc. that we
+1 to making 2.6 the last JDK6 release.
If we want, 2.7 could be a parallel release or one soon after 2.6. We could
upgrade other dependencies that require JDK7 as well.
On Fri, Jun 27, 2014 at 3:01 PM, Arun C. Murthy a...@hortonworks.com wrote:
Thanks everyone for the discussion. Looks like
On Tue, Jun 24, 2014 at 4:44 PM, Alejandro Abdelnur t...@cloudera.com
wrote:
After reading this thread and thinking a bit about it, I think it should be
OK such move up to JDK7 in Hadoop
I agree with Alejandro. Changing minimum JDKs is not an incompatible change
and is fine in the 2 branch.
I'm also +1 for getting us to JDK7 within the 2.x line after reading the
proposals and catching up on the discussion in this thread.
Has anyone yet considered how to coordinate this change with downstream
projects? Would we request downstream projects to upgrade to JDK7 first
before we make the
Chris,
Compiling with jdk7 and doing javac -target 1.6 is not sufficient, you are
still using jdk7 libraries and you could use new APIs, thus breaking jdk6
both at compile and runtime.
you need to compile with jdk6 to ensure you are not running into that
scenario. that is why i was suggesting
+1 (non-binding) for 2.5 to be the last release to ensure JDK6.
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
I understood the plan for avoiding JDK7-specific features in our code, and
your suggestion to add an extra Jenkins job is a great way to guard against
that. The thing I haven't seen discussed yet is how downstream projects
will continue to consume our built artifacts. If a downstream project
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:
That classpath policy was explicitly added because we can't lock down our
dependencies for security/bug fix reasons, and also because if we do update
something explicitly, their transitive dependencies can change -beyond our
control.
https://issues.apache.org/jira/browse/HADOOP-9555 is an example
Tx for the new thread Andrew, hopefully it can attract more eyes.
Here's what I am behind - a modified proposal C.
- Overall I wouldn't think about EOL of JDK7 and/or JDK8 specifically given
how long it has taken for JDK6 life-cycle to end. We should try to focus on
JDK7 only for now.
- As we
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
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
+1, though I think 2.5 may be premature if we want to send a warning note
last ever. That's an issue for followon when in branch 2.
Guava and protobuf.jar are two things we have to leave alone, with the
first being unfortunate, but their attitude to updates is pretty dramatic.
The latter? We all
Alejandro,
On Tue, Jun 24, 2014 at 4:44 PM, Alejandro Abdelnur t...@cloudera.com
wrote:
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 Jun 24, 2014, at 4:22 PM, Andrew Wang andrew.w...@cloudera.com wrote:
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
20 matches
Mail list logo
