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.
