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
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
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
Hi all,
Forking this thread as requested by Vinod. To help anyone who's catching up
with this thread, I've written up a wiki page containing what I think are
the proposals under discussion. I did my very best to make this as
fact-based and disinterested as possible; I really appreciate the
Andrew
thanks for writing the proposal.
In the proposal you mention:
Dropping support for a JDK in a minor release is incompatible, so this
would require a change to our compatibility guidelines.
Why is dropping a JDK incompatible?
sanjay
On Jun 24, 2014, at 11:17 AM, Andrew Wang
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
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
Hello,
I do know scenarios which involve sticking with Java 6. Mostly related to
supporting Applications Servers of (Big) 3 Letter companies (both).
I dont see that in an Hadoop cluster. Especially given that expressiveness of
Java 8 and also Performance of Java 7 are both important in Big
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
16 matches
Mail list logo
