Ensure java 6 source compatibility about denominator HOT 4 CLOSED

So this is a problem with the jdk in general. Source compatibility will
keep you from using language features, so 1.6 will flag if you use lambdas
or multicatches, or diamond operators but not if you use a method on a
class that didn't exist in 1.6. Only real way to catch would be to run
compilation and tests in the target jdk. Our Nebula plugins won't run in
JDK6 because we started to use JDK7 features and since 6 was EOL a long
time ago and 7 is EOL at the end of April we won't move the plugins
themselves to be JDK6 compatible. Cloudbees and TravisCI are both set to
run in JDK7 so the pull request jobs should fail on JDK8 only methods.

On Tue, Mar 17, 2015 at 8:43 AM, Adrian Cole [email protected]
wrote:

Assigned #344 #344 to
@rspieldenner https://github.com/rspieldenner.

—
Reply to this email directly or view it on GitHub
#344 (comment).

from denominator.

from denominator.

Ok.

Looks like we would need to have javac's boot classpath set on the host we are building in order to enforce a language level.

$ cat MyIterator.java 
class MyIterator implements java.util.Iterator<String> {
  public boolean hasNext() {
    return false;
  }

  public String next() {
    throw new IllegalStateException("I said I don't have next!");
  }
  // note this lacks remove()!
}
# Note this didn't fail as I didn't set bootclasspath to correspond with the source version
$ javac -source 1.6 MyIterator.java 
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=utf8
warning: [options] bootstrap class path not set in conjunction with -source 1.6
1 warning

from denominator.

I think adding animal-sniffer for 1.6 is probably the highest leverage action to take.

Travis running 1.7 will catch most other things that would affect android (ex. accidental use of lambda or default methods).

from denominator.