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 "String
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 that
+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 wrote:
> Thanks everyone for the discussion. Looks like we have come to a pr
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 ar
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 just
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
wrote:
> Hi all, responding to multiple messag
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 nee
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
upgr
+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
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 the
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 m
On Tue, Jun 24, 2014 at 4:44 PM, Alejandro Abdelnur
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. (Although I think
On Jun 24, 2014, at 4:22 PM, Andrew Wang 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 haven't read
> up on the MR
Alejandro,
On Tue, Jun 24, 2014 at 4:44 PM, Alejandro Abdelnur
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 JDK7 in p
+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 a
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
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 explai
While we haven't codified this in our compatibility guidelines, dropping a
Java version seems to me like change that needs to happen alongside a major
release. In plain talk, it has the ability to break everything for users
who aren't doing anything particularly unreasonable.
I don't think we sho
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
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
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 wrote:
> https://wiki.apache.org/hadoop/MovingToJdk7and8
>
> I think based
21 matches
Mail list logo