It looks to me that the majority of this thread welcomes JDK7. Just to reiterate, there are two separate questions here:
1. When should hadoop-trunk can be only built on top of JDK7? 2. When should hadoop-branch-2 can be only built on top of JDK7? The answers of the above questions directly imply when and how hadoop can break the compatibility for JDK6 runtime. It looks that there are quite a bit of compatibility concerns of question (2). Should we focus on question (1) and come up with a plan? Personally I'd love to see (1) to happen as soon as possible. ~Haohui On Sun, Apr 6, 2014 at 11:37 AM, Steve Loughran <ste...@hortonworks.com>wrote: > On 5 April 2014 20:54, Raymie Stata <rst...@altiscale.com> wrote: > > > To summarize the thread so far: > > > > a) Java7 is already a supported compile- and runtime environment for > > Hadoop branch2 and trunk > > b) Java6 must remain a supported compile- and runtime environment for > > Hadoop branch2 > > c) (b) implies that branch2 must stick to Java6 APIs > > > > I wonder if point (b) should be revised. We could immediately > > deprecate Java6 as a runtime (and thus compile-time) environment for > > Hadoop. We could end support for in some published time frame > > (perhaps 3Q2014). That is, we'd say that all future 2.x release past > > some date would not be guaranteed to run on Java6. This would set us > > up for using Java7 APIs into branch2. > > > > I'll let others deal with that question. > > > > > > An alternative might be to keep branch2 on Java6 APIs forever, and to > > start using Java7 APIs in trunk relatively soon. The concern here > > would be that trunk isn't getting the kind of production torture > > testing that branch2 is subjected to, and won't be for a while. If > > trunk and branch2 diverge too much too quickly, trunk could become a > > nest of bugs, endangering the timeline and quality of Hadoop 3. This > > would argue for keeping trunk and branch2 in closer sync (maybe until > > a branch3 is created and starts getting used by bleeding-edge users). > > However, as just suggested, keeping them in closer sync need _not_ > > imply that Java7 features be avoided indefinitely: again, with > > sufficient warning, Java6 support could be sunset within branch2. > > > > One thing we could do is have a policy towards new features where there's > consensus that they won't go into branch-2, especially things in their own > JARs. > > Here we could consider a policy of build set up to be Java 7 only, with > Java7 APIs. > > That would be justified if there was some special java 7 feature -such as > its infiniband support. Add a feature like that in its own module (under > hadoop-tools, presumably), and use Java7 and Java 7 libraries. If someone > really did want to use the feature in hadoop-2, they'd be able to, in a > java7+ only backport. > > > > > > On a related note, Steve points out that we need to start thinking > > about Java8. YES!! Lambdas are a Really Big Deal! If we sunset > > Java6 in a few quarters, maybe we can add Java8 compile and runtime > > (but not API) support about the same time. This does NOT imply > > bringing Java8 APIs into branch2: Even if we do allow Java7 APIs into > > branch2 in the future, I doubt that bringing Java8 APIs into it will > > ever make sense. However, if Java8 is a supported runtime environment > > for Hadoop 2, that sets us up for using Java8 APIs for the eventual > > branch3 sometime in 2015. > > > > > Testing Hadoop on Java 8 would let the rest of the stack move forward. > > In the meantime, can I point out that both Scala-on-Java7 and > Groovy-on-Java 7 offer closures quite nicely, with performance by way of > INVOKEDYNAMIC opcodes. > > -steve > > -- > 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. > -- 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.
