I've been using JDK7 for Hadoop development for a while now, and I know a lot of other folks have as well. Correct me if I'm wrong, but what we're talking about here is not "moving towards JDK7" but "breaking compatibility with JDK6."
There are a lot of good reasons to ditch JDK6. It would let us use new APIs in JDK7, especially the new file APIs. It would let us update a few dependencies to newer versions. I don't like the idea of breaking compatibility with JDK6 in trunk, but not in branch-2. The traditional reason for putting something in trunk but not in branch-2 is that it is new code that needs some time to prove itself. This doesn't really apply to incrementing min.jdk-- we could do that easily whenever we like. Meanwhile, if trunk starts accumulating jdk7-only code and dependencies, backports from trunk to branch-2 will become harder and harder over time. Since we make stable releases off of branch-2, and not trunk, I don't see any upside to this. To be honest, I see only negatives here. More time backporting, more issues that show up only in production (branch-2) and not on dev machines (trunk). Maybe it's time to start thinking about what version of branch-2 will drop jdk6 support. But until there is such a version, I don't think trunk should do it. best, Colin On Fri, Apr 4, 2014 at 3:15 PM, Haohui Mai <h...@hortonworks.com> wrote: > I'm referring to the later case. Indeed migrating JDK7 for branch-2 is more > difficult. > > I think one reasonable approach is to put the hdfs / yarn clients into > separate jars. The client-side jars can only use JDK6 APIs, so that > downstream projects running on top of JDK6 continue to work. > > The HDFS/YARN/MR servers need to be run on top of JDK7, and we're free to > use JDK7 APIs inside them. Given the fact that there're way more code in > the server-side compared to the client-side, having the ability to use JDK7 > in the server-side only might still be a win. > > The downside I can think of is that it might complicate the effort of > publishing maven jars, but this should be an one-time issue. > > ~Haohui > > > On Fri, Apr 4, 2014 at 2:37 PM, Alejandro Abdelnur <t...@cloudera.com>wrote: > >> Haohui, >> >> Is the idea to compile/test with JDK7 and recommend it for runtime and stop >> there? Or to start using JDK7 API stuff as well? If the later is the case, >> then backporting stuff to branch-2 may break and patches may have to be >> refactored for JDK6. Given that branch-2 got GA status not so long ago, I >> assume it will be active for a while. >> >> What are your thoughts on this regard? >> >> Thanks >> >> >> On Fri, Apr 4, 2014 at 2:29 PM, Haohui Mai <h...@hortonworks.com> wrote: >> >> > Hi, >> > >> > There have been multiple discussions on deprecating supports of JDK6 and >> > moving towards JDK7. It looks to me that the consensus is that now hadoop >> > is ready to drop the support of JDK6 and to move towards JDK7. Based on >> the >> > consensus, I wonder whether it is a good time to start the migration. >> > >> > Here are my understandings of the current status: >> > >> > 1. There is no more public updates of JDK6 since Feb 2013. Users no >> longer >> > get fixes of security vulnerabilities through official public updates. >> > 2. Hadoop core is stuck with out-of-date dependency unless moving towards >> > JDK7. (see >> > http://hadoop.6.n7.nabble.com/very-old-dependencies-td71486.html) >> > The implementation can also benefit from it thanks to the new >> > functionalities in JDK7. >> > 3. The code is ready for JDK7. Cloudera and Hortonworks have successful >> > stories of supporting Hadoop on JDK7. >> > >> > >> > It seems that the real work of moving to JDK7 is minimal. We only need to >> > (1) make sure the jenkins are running on top of JDK7, and (2) to update >> the >> > minimum required Java version from 6 to 7. Therefore I propose that let's >> > move towards JDK7 in trunk in the short term. >> > >> > Your feedbacks are appreciated. >> > >> > Regards, >> > Haohui >> > >> > -- >> > 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 >> > > -- > 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.
