Find out what we can do to release for jdk6 instead of jdk7

[julienrf]

No description provided.

[lrytz]

We'll have the same issue for all modules, so let's consolidate the discussion here. cc @ashawley @gourlaysama @Sciss @xuwei-k @SethTisue @retronym

It's no longer possible to publish to sonatype when running on Java 6, see here, as @MasseGuillaume noted in this commit: f43e772.

In general, we'd like to build releses of Scala modules for Scala 2.11 on Java 6 to make sure the generated artifacts don't have accidental dependencies on Java APIs that don't exist in Java 6.

A famous case was String.isEmpty, that was between Java 5 and 6. In 5, the method didn't exist, but it was available in Scala as an extension method. The method was added in Java 6. So when compiling on 6, the compiler would not use the member method, and the resulting classfile would not work on Java 5.

To minimize the risk, we could run the 2.11 build on both Java 6 and 8 for CI validation, but use only 8 for publishing. This would prevent direct use of APIs that don't exist on Java 6. There's still a risk for cases like the extension method above, but it's a small one. In order to be really sure, we could compare the classfiles built on 6 and 8 during CI validation, they should be identical.

[eed3si9n]

It's not going to be as thorough as comparing the *.class files, but sbt 1.2.0 will add Cross JDK forking java++ command intended for running forked tests.

[retronym]

Can we just run with SBT with Java 8 (or later), and set javaHome := Some(file("/path/to/java6")?

That ought to use Java 6's classpath for javac and scalac, but do the actual interaction with Sonatype from the more modern JVM.

[lrytz]

Good point to switch the JVM. Maybe it's easy to switch to 8 for the publish-signed step, for example with a scala -e ... command? Just running sbt publish-signed would not work, sbt would re-build the project because the classpath changed.

[MasseGuillaume]

I implemented @retronym suggestion: #83