+1 with reservations. This seems like a big API change, not because our dependency changes, but doesn't it force all consumers to change to Java 7 as well if new language features are used in the client? Looks like Java 6 compiled iterators should work without change.
I wonder if would make sense to: - move client to its own module (out of core), - build a Java 6 distribution of the client in addition to the Java 7 release, and - refrain from using Java 7 features in the client until a 2.0 release -----Original Message----- From: Sean Busbey [mailto:bus...@cloudera.com] Sent: Monday, June 03, 2013 7:05 PM To: dev@accumulo.apache.org Subject: Re: [VOTE] JDK 1.7 - Switch for Accumulo 1.6.0 On Mon, Jun 3, 2013 at 5:04 PM, Josh Elser <josh.el...@gmail.com> wrote: > <snip> Also, some quick searching leads me to believe that 1.6 bytecode will run > on a 1.7 JVM, but not vice versa. Does anyone know if this is the > case? I apologize if I'm bringing up an already-discussed subject. > <snip> > Just to confirm, the JDK7 compatibility guide says JDK7 compiled code won't work on a Java 6 VM[1]: > The class file version for Java SE 7 is 51, as per the JVM > Specification, because of the invokedynamic byte code > introduced by JSR 292. Version 51 class files produced by the Java SE > 7 compiler cannot be used in Java SE 6. [1]: http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#binary -- Sean