Sorry, coming to discussion late. We all agreed that 2.6 would the *last* release supporting JDK6 and hadoop-2.7 would drop support for JDK6. We could easily do 2.7 right after 2.6 (maybe with few critical bug-fixes) with the defining feature of 2.7 being *JDK7 only*. I've checked with HBase, Pig and other communities and they are good with this. I'm thinking I'll follow up 2-3 wks after 2.6 goes out to release 2.7 which drops JDK6.
We can certainly add support for JDK8 as early as 2.7 if there are volunteers - clearly we won't make it depend on JDK8 features right away; since it would still need to support JDK7. To recap: hadoop-2.7 onwards would be minimum JDK7, with potential support for JDK8. We can revisit our discussion from a few months ago to discuss when we *drop* support for JDK7; clearly something I'd like to avoid doing in haste. thanks, Arun On Thu, Sep 18, 2014 at 8:41 AM, Alejandro Abdelnur <tuc...@gmail.com> wrote: > Am I missing something, or we already agreed that after 2.5 release we > would move trunk and branch-2 to java 7? > > On Wed, Sep 17, 2014 at 3:33 PM, Travis Thompson < > travis.r.thomp...@gmail.com> wrote: > >> There's actually an umbrella JIRA to track issues with JDK8 >> (HADOOP-11090), in case anyone missed it. >> >> At LinkedIn we've been running our Hadoop 2.3 deployment on JDK8 for >> about a month now with some mixed results. It definitely works but >> there are issues, mostly around virtual memory exploding. The reason >> we took the jump early is there is a company wide push to move to JDK8 >> ASAP, I suspect this isn't something unique to LinkedIn. To get this >> to work with security enabled, we've had to apply patches not even in >> trunk yet because they break JDK6 compatibility. >> >> From my perspective, based on what I've seen and people I've talked >> to, there is a huge push to move to JDK8 ASAP so it's becoming >> increasingly urgent to at least get support to run on JDK8. >> >> On Wed, Sep 17, 2014 at 9:55 AM, Allen Wittenauer <a...@altiscale.com> >> wrote: >> > >> > On Sep 17, 2014, at 2:47 AM, Steve Loughran <ste...@hortonworks.com> >> wrote: >> >> >> >> I don't agree. Certainly the stuff I got into Hadoop 2.5 nailed down >> the >> >> filesystem binding with more tests than ever before. >> > >> > FWIW, based upon my survey of JIRA, there are a lot of unit >> test fixes that are only in trunk. >> > >> >> But I am also aware of large organisations that are still on Java 6. >> >> Giving a clear roadmap "move to Java 7 now, java 8 in "XX months" can >> help >> >> them plan. >> > >> > Planning is a big thing. That’s one of the reasons why it’d be >> prudent to start doing 3.0+JDK8 now as well. Even if April slips, other >> projects and orgs are already moving to 8. These people wonder what our >> plans are so that they can run one JVM. Right now our answer is ¯\_(ツ)_/¯ . >> > >> > I’m sure I can dig up a user running Hadoop 0.13 because it ran >> on JDK5. That doesn’t mean the open source project should stall because >> certain orgs don’t/can't upgrade. >> > >> >>> >> >>> Drop the 2.6.0 release, branch trunk, and start rolling a >> >>> 3.0.0-alpha with JDK8 as the minimum. 2.5.1 becomes the base for all >> >>> sustaining work. This gives the rest of the community time to move >> to JDK8 >> >>> if they haven’t already. For downstream vendors, it gives a roadmap >> for >> >>> their customers who will be asking about JDK8 sooner rather than >> later. By >> >>> the time 3.0 stabilizes, we’re probably looking at April, which is >> perfect >> >>> timing. >> >>> >> >>> >> >> That delays getting stuff out too much; if april slips it becomes a >> long >> >> time since an ASF release came out. >> > >> > I’m assuming you specifically mean a ‘stable’ release. If, as >> everyone seems to be saying, that 3.x doesn’t have that much different than >> 2.x, doesn’t this mean that 3.x should be stable much quicker than 2.x >> took? In other words, if 2.5 is stable and the biggest differences between >> it and trunk is the majority of code (450+ JIRAs as of yesterday afternoon) >> that just also happens to be in 2.6, doesn’t it mean 2.6 is also extremely >> unstable? (Thus supporting my conjecture that 2.6 is going to be a >> problematic release?) >> > >> >> Saying "you must run on Java 8 for >> >> this" will only scare people off and hold back adoption of 3.x, >> leaving 2.5 >> >> as the last release that ends up being used for a while; the new 1.0.4 >> > >> > From the outside, trunk looks a lot of 0.21 already. From what >> I can tell, there is zero motivation to get it out the door and on a >> roadmap. Primarily because there is little different between trunk and >> branch-2. This is a very dangerous place to be as those few differences, >> some measured in years old, rot and wither. :( >> > >> >> Here's an alternative >> >> >> >> -2.6 on java 6, announce EOL for Java 6 support >> >> -2.7 on Java 7, state that the lifespan of j7 support will be some >> bounded >> >> time period (12-18 mo) >> >> -trunk to build and test on Java 8 in jenkins alongside java 7. For >> that to >> >> be useful someone needs to volunteer to care about build failures. are >> you >> >> volunteering, Allen? >> > >> > This seems reasonable, except what release should folks who >> *require* java 8 use? Nightly trunk+patches builds? How do downstream >> projects test? Should JDK8 fixes be going into a branch? (I’m making the >> assumption that fixes for JDK8 are not backward compatible with JDK7. >> Hopefully they are, but given our usage of private APIs…) >> > >> > I’ve been approached by a few people over the past month+ if >> I’d be interested in or will be RM’ing 3.0. I’m seriously considering it >> esp given a) it’d be a nice learning experience for me b) my “day job” >> makes it practical time-wise c) I seem to be the only one concerned enough >> about quite a bit of stale code to get it out the door. >> > >> > FWIW, I’m in the process of moving my test vm to JDK8 to see >> how bad the damage truly is right now. Based on others, it seems security >> doesn’t work, which is a pretty big deal. I can certainly start posting >> trunk builds on people.apache.org if folks are interested. >> > >> >> -we switch trunk to Java 7 NOW. That doesn't mean a rewrite fest going >> >> through all catch() statements making them multicatch, and the same for >> >> string case. >> > >> > Yup. There’s little reason *not* to switch trunk to JDK7 now. >> > > -- -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ -- 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.
