hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: Moving to JDK7, JDK8 and new major releases
Date Sat, 28 Jun 2014 15:38:49 GMT
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 "StringBuilder" is better.

On 27 June 2014 19:26, Andrew Wang <andrew.wang@cloudera.com> wrote:

> 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 need to have all the fun
> deps like Guava on the classpath. I'm told Spark sticks a newer Guava at
> the front of the classpath and the HDFS client still works okay, but this
> is more happy coincidence than anything else. While we're leaking deps,
> we're in a scary situation.

very good point.

> API compat to me means that an app should be able to run on a new minor
> version of Hadoop and not have anything break. MAPREDUCE-4421 sounds like
> it allows you to run e.g. 2.3 MR jobs on a 2.4 YARN cluster, but what
> should also be possible is running an HDFS 2.3 app with HDFS 2.4 JARs and
> have nothing break. If we muck with the classpath, my understanding is that
> this could break.
I think this is possible by having the app upload all the JARs...I need to
experiment here myself.

> Chris, thanks for bringing up the ecosystem. For CDH5, we standardized on
> JDK7 across the CDH stack, so I think that's an indication that most
> ecosystem projects are ready to make the jump. Is that sufficient in your
> mind?
+1, we've had no complaints about things not working on Java 7. It's been
out a long time. IF you look at our own code, the main thing that broke
were tests -due to junit test case ordering- and not much else.

> For the record, I'm also +1 on the Tucu plan. Is it too late to do this for
> 2.5? I'll offer to help out with some of the mechanics.

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.

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