Document unsupport for Java 6
pauldraper opened this issue · 3 comments
Several days ago, support for Java 6 was removed.
This is somewhat surprising as scalac, scala-library, and sbt all target Java 6.
Since the Java 7+ requirement is unusual within the Scala/SBT community (at least until Scala 2.12, when it becomes Java 8), this should at least be well documented.
(FYI, my vote would be to keep Java 6 compatible, since it compiles to Java 6 bytecode anyway. The only gain is a few APIs in the JRE, which already have other workable solutions.)
This is somewhat surprising as scalac, scala-library, and sbt all target Java 6.
We asked in the community and received only positives feedbacks on upgrading.
my vote would be to keep Java 6 compatible, since it compiles to Java 6 bytecode anyway
Depending on what jvm.target you choose.
The only gain is a few APIs in the JRE, which already have other workable solutions
We had a lot of issues with user permissions ( and still struggling on windows ), but things are easier with Java 7.
this should at least be well documented
With the next release candidate we'll cover that.
We asked in the community and received only positives feedbacks on upgrading.
Hm, sorry I didn't contribute. My entire toolchain uses Java 6, from Scala to SBT to every plugin I use (until now). You may think anyone who uses Java 6 is dumb, and I might agree with you.
Though for one reason or another, these other tools still use Java 6.
Depending on what jvm.target you choose.
True, but only technically. Java 7 bytecode emission by scalac is experimental, and will never be fully supported. And sbt-native-packager targets Java 6 bytecode (currently, at least).
With the next release candidate we'll cover that
Thanks. This is particularly important since the bytecode (Java 6) will be happily be executed until it happens to hit an incompatible Java library call (Java 7).
Hopefully this won't be a problem for most anyway.
The 0.8.x branch will remain java 6 compatible and I can understand your concerns.
At this point we have a very small part depending on Java 7 libs. Support for a Java 6
compatible branch is imaginable, but needs some code discipline.
Unfortunately we have not enough data to guide our decisions ( thanks here to all who provide feedback ). So a lot of things get reported "when it breaks", which feels like testing things live. This is a reason for the many milestone and release candidates. Having said that. A backup plan for unhappy Java 6 users might be advisable.