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 should accept Hadoop's compatibility behavior 6 years ago as precedent for what we can do now. That was before Hadoop 1.0. And we probably have several orders of magnitude more production users. I also don't think we should accept library upgrades as precedent. While this may make sense in specific situations, I definitely don't think this is OK in general. I'd be very nervous about updating Guava outside of major version upgrade. Lastly, I think the claim that nobody is running in production on Java 6 is unsubstantiated. We need to think about a JDK upgrade in terms of what its implications are for users, not in terms of what other kinds of compatibility we've broken that's loosely analogous. -Sandy On Tue, Jun 24, 2014 at 3:42 PM, Vinod Kumar Vavilapalli <vino...@apache.org > wrote: > 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 have seen, a lot (majority?) of orgs on Hadoop have moved beyond > JDK6 and are already running on JDK7. So upgrading to JDK7 is more of a > reflection of reality (to quote Steve) than it in itself being a disruptive > change. > - We should try decoupling the discussion of major releases from JDK > upgrades. We have seen individual libraries getting updated right in the > 2.x lines as and when necessary. Given the new reality of JDK7, I don't see > the 'JDK change' as much different from the library upgrades. > > We have seen how long it has taken (and still taking) users and > organization to move from Hadoop 1 to Hadoop 2. A Hadoop 3/4 that adds > nothing else other than JDK upgrades will be a big source of confusion for > users. A major version update is also seen an opportunity for devs to break > APIs. Unless we have groundbreaking 'features' (like YARN or > wire-compatibility in Hadoop-2) that a majority of users want and that > specifically warrant incompatible changes in our APIs or wire protocols, we > are better off separating the major-version update discussion into ints own. > > Irrespective of all this, we should actively get behind better isolation > of user classes/jars from MapReduce classpath. This one's been such a long > running concern, it's not funny anymore. > > Thanks, > +Vinod > > On Jun 24, 2014, at 11:17 AM, Andrew Wang <andrew.w...@cloudera.com> > wrote: > > > 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 > > constructive discussion we've had so far. If you believe you have a > > proposal pending, please feel free to edit the wiki. > > > > https://wiki.apache.org/hadoop/MovingToJdk7and8 > > > > I think based on our current compatibility guidelines, Proposal A is the > > most attractive. We're pretty hamstrung by the requirement to keep the > > classpath the same, which would be solved by either OSGI or shading our > > deps (but that's a different discussion). > > > > Thanks, > > Andrew > > > -- > 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. >
