Decide what Java version to support in 1.x

[dwijnand]

I might be being forgetful but what Java version do we want to support in 1.x?

Related, do we want to test additional Java versions on Travis?

For reference, this is the current status quo:

| repo                    | Java 6?  | Java 7?                    | Java 8?    |
| ----------------------- | -------- | -------------------------- | ---------- |
| sbt/sbt                 | openjdk6 | (oraclejdk7 commented out) | no         |
| sbt/ivy                 | openjdk6 | no                         | no         |
| sbt/launcher            | openjdk6 | (oraclejdk7 commented out) | no         |
| sbt/io                  | no       | oraclejdk7 (not specified) | no         |
| sbt/serialization       | openjdk6 | openjdk7 & oraclejdk7      | no         |
| sbt/util                | no       | oraclejdk7 (not specified) | no         |
| sbt/incrementalcompiler | openjdk6 | no                         | no         |
| sbt/librarymanagement   | no       | oraclejdk7                 | oraclejdk8 |

[dwijnand]

Seems the consensus is to definitely drop Java 6.

We're not sure if we can choose to drop Java 7, as it might impact that the bytecode generated from compiling can't run (or can't run reliably) on JVM 7.

TBD, we probably want to speak to other tools teams, such as the scalac team, Scala IDE team and IntelliJ team. Maybe even Akka, Play and Spark teams?

[lrytz]

Seems the consensus is to definitely drop Java 6.

I'm not following sbt's lists / gitter, so I don't have the background of how this consensus was reached, sorry if I'm repeating some arguments. I might also lack knowledge of some sbt features that fix the problem I describe.

If Scala 2.11 is still in wide use by the time sbt 1.0 is released, I think sbt 1.0 should support JDK 6. I understand you can build a 2.11 project on JDK 7 / 8 and then still run it on JDK 6. But the problem is that you have the JDK 7 / 8 Java standard library on the classpath, so you might accidentally use new API, and the bytecode would not work when somebody runs it on JDK 6.

[dwijnand]

Hi @lrytz thank you for chiming in.

Consensus was with @eed3si9n and @Duhemm in a hangout.

What you describe isn't any more of a problem than what already is the case: if I run sbt 0.13.9 on JDK 8 I have no guarantees that the program I compile would work on JRE 7.

The only tool I know to safe-guard against this is sbt-javaversioncheck, and we use it in sbt's build itself for this purpose. It's a rather blunt tool (simply need to be running the right version of the JDK) but it works. A better tool would be a port of animal-sniffer-maven-plugin to sbt and Scala.

[lrytz]

at you describe isn't any more of a problem than what already is the case: if I run sbt 0.13.9 on JDK 8 I have no guarantees that the program I compile would work on JRE 7.

Not exactly: right now I have the option to set up my build env to use JDK 6 and therefore make sure it will run on JDK 6. that's what we do in case of scala/scala.

[dwijnand]

Ah, I see what you mean now. You're right, thanks @lrytz.

[eed3si9n]

If Scala 2.11 is still in wide use by the time sbt 1.0 is released, I think sbt 1.0 should support JDK 6.

Why? I see no reason to support JDK that's been declared end of life in February 2013. If someone for whatever reason needs JDK 6 they can use sbt 0.13. I think supporting JDK 7 that's been declared end of life in April 2015 borders on being irresponsible on sbt 1.0's part, but I understand that some organization might be moving slower to Java 8.

The primary motivation for dropping Java 6 is so we can freely use Java 7 or 8 feature in sbt, and also to encourage the community to move forward.

[ritschwumm]

in my experience, often enough it's not about moving to java 8 - it's about getting rid of java 6, right after the old java 1.3 and 1.4 projects have finally been migrated.

imho, sbt should support JDKs as low as possible with the scala version it's using. with scala 2.12, support for JDK 6 will be gone anyway.

[dwijnand]

I'm happy to move to JDK 7 for sbt 1.0, even if it makes it harder to build projects that are guaranteed to work on Java 6.

Anyone who wants to both use sbt 1.0 and reliably build projects for Java 6 would have to develop a port for animal-sniffer.

But I also agree that given Java 7 was declared end of life 9 months ago (and sbt 1.0 isn't due for a while still), I would ask for stronger objections to blocking progress in sbt (as well as the entire ecosystem of sbt plugins whom we provide support and for whom we guarantee backwards compatibility) outside of "some organisations are slow" and "some libraries haven't yet been released for Java 8 yet". There's nothing stopping slow organisations and slow library maintainers (and users of such libraries) to stay on sbt 0.13.

Remember Java 8 was released almost 2 years ago: March 2014.

[eed3si9n]

Also consider the reason why sbt 0.13 is built on JDK 6. It's because we promised binary compatibility for 0.13.x upgrades. If we go with JDK 6, we're going to be stuck with supporting it for another 12 ~ 24 month life cycle. This is the perfect opportunity to drop old stuff.

sbt 1.0 doesn't even exist yet, so I don't think I'm holding any project as hostage here. I'd be concerned about Play community since they are on sbt, but thankfully they already require JDK 8 in their latest.

[ekrich]

Since Scala 2.12 will be Java 8 I think it makes sense to be sbt 1.0 to be Java 8 only. This is provided the release of sbt 1.0 shortly follows 2.12. http://www.scala-lang.org/news/2016-schedule/

[SethTisue]

if 1.0 will be JDK 8 only, should build definitions be 2.12 instead of 2.11?

[ijuma]

Java 9 will support compiling for older platform versions by the way: http://openjdk.java.net/jeps/247

In terms of timelines for SBT 1.0, are we talking a few months, more than 6 months or more than a year?

[dwijnand]

More than 6 months is probably the best answer right now. I'm hoping to be able to help it be less though.

[ekrich]

My thought was that because Scala 2.12 is JDK8 with only 1.8 bytecode it would make sense for sbt to follow suit. Both sbt and build definitions compile to 1.8 byte code. Then you get smaller code and hopefully better performance via the java lambdas.

[ekrich]

Play and Akka support Java APIs so they want to make the Java and Scala APIs more similar so they want Java lambdas which forces the systems to be Java 8 only. Looks like current release Play 2.4 requires Java 8. https://www.playframework.com/documentation/2.4.x/Migration24

[ijuma]

It does seem reasonable to me to go for Scala 2.12 and Java 8 given the expected timeline and what other projects are doing. There is a risk that it may delay adoption of SBT 1.0 for some projects, but that seems OK when compared to being stuck with Java 6/7 for another 12-24 months. Many open-source projects (Akka, Cassandra, Play, Scala 2.12) already require Java 8 and I expect the number to grow once Java 9 is released in March of next year (for projects that support the 2 most recent JDK releases).

[dwijnand]

Given the whole plugin ecosystem would need to recompile both for binary incompatibility with Scala and with source-incompatibility in sbt 1.0, perhaps it does make sense to just go straight for Scala 2.12.

[sjrd]

We had a similar discussion for Scala.js in July 2015: https://github.com/scala-js/scala-js/pull/1807 In the core team, we wanted to drop JDK 6 support, but the maintainers of some popular Scala libraries argued against it, especially @bvenners about ScalaTest. I suggest you read the discussion.

[ijuma]

@srjd, the discussion there was a bit different. Bill said:

"That aside I wonder why you wouldn't just wait until Scala 2.12, when the whole Scala ecosystem will need to do a build on Java 6 for 2.10, 2.11, and another build on Java 8 for 2.12. I'm not sure what the latest roadmap for Scala 2.12 is, but surely it isn't that far off (for some value of "far off")."

Which is fine for the proposal of moving to Scala 2.12 and Java 8 at the same time.

[sjrd]

@ijuma That argument will start being relevant when the eco-system stops supporting 2.11, not when it starts supporting 2.12. Seeing how many libraries are still supporting 2.10, I don't think this will happen anytime soon (for better or worse).

I'm not arguing myself against choosing 2.12/JDK 8. I'm just pointing out that the larger community may have different requirements--and therefore opinions--that the maintainers of sbt, just as they had different views than us.

(In fact, I would be glad if sbt 1.0 chose Scala 2.12 and JDK 8. That would be a good excuse for us to drop JDK 7 and 8 :-p)

[fommil]

I vote latest and greatest for both Java and Scala versions. Java for NIO and Scala for future proofing of plugins. It doesn't imply anything on my projects, which might need to be Java 6

[He-Pin]

I think the sbt part should be keep support the latest maintained scala version.

For now,the scala 2.12 is not released,it should be 2.10,once the scala 2.12 is out,we should build it on scala 2.11. and once scala 2.13 is out,we could finally switch to 2.12.

Keep lack of one release cycle of scala help the community.

We could totally switch to scala 2.12 once the next next scala main release it out.

[eed3si9n]

To throw in another wrench into this situation, sbt project is the maintainer of the Scala incremental compiler. sbt's code base gets republished, gets used by ScalaIDE and Zinc, which then is called by other build tools as well.

@SethTisue

if 1.0 will be JDK 8 only, should build definitions be 2.12 instead of 2.11?

I haven't decided whether we should target JDK 7 or 8. I'm definitely open to build definitions in Scala 2.12.

@ijuma

There is a risk that it may delay adoption of SBT 1.0 for some projects, but that seems OK when compared to being stuck with Java 6/7 for another 12-24 months.

+1. If the key downside is mostly around adoption rate, then it's a social discussion, which probably won't have a clearcut answer.

@sjrd

We had a similar discussion for Scala.js in July 2015: scala-js/scala-js#1807

Very informative. Thanks for the link.

[He-Pin]

@eed3si9n

You could fire a twitter poll for this,cause it's social right?

[eed3si9n]

@hepin1989 I'd hate to take a poll and completely ignore it afterwards.

[He-Pin]

@eed3si9n I think cause typesafe is currently maintain scala 2.11.x,so as a build tool,sbt may be a little conservative and switch to 2.11.x for sbt 1.0?but still it depends how long the 1.0 will take to be released,if there is a scala 2.13,and scala 2.12 is in the maintaining state,then we could finally switch to 2.12 :)

[fommil]

regardless of which version of java we use, can we use OpenJDK instead of OracleJDK?

[eed3si9n]

@hepin1989 I am a member of Reactive Platform team that maintains the commercial offering by Typesafe called Reactive Platform. The entire stack from Scala, Play, Akka, as well as feature not available to OSS (such as Akka Monitoring) is supported for 24 months. The current stable release 15v09 targets JDK 8. https://www.typesafe.com/products/typesafe-reactive-platform

[He-Pin]

@eed3si9n I know,currently release of Akka Play is target JDK 8 and yes,JDK 6 support is commercial,I don't know how about SBT.

[dwijnand]

@sjrd Thank you for that link.

What's also interesting from that link is when @SethTisue mentions dbuild, which builds on sbt.. so I wonder what will/would happen there if/when sbt 1.0 goes Scala 2.12/Java 8.. talk about "crazy nineteen-dimensional matrix of every possible combination of All The Things".

@hepin1989 Note that this decision is (or actually, has become) about:

• what JDK is used to build sbt, allowing sbt 1.0 to use some new and better APIs in the Java standard library, such as the IO APIs which we use a lot
• what version of the JDK is required to run sbt
• what versions of the JDK and Scala you write your build definition files in, and
• what versions of the JDK and Scala sbt plugins are written in

Missing from that list is what version of Scala you can compile, which would continue to include Scala 2.11 (and 2.10, 2.9.. perhaps not 2.8, but TBD).

@fommil Travis doesn't currently support openjdk8 unfortunately:

• https://docs.travis-ci.com/user/languages/java
• https://github.com/travis-ci/travis-ci/issues/1647 (confusing ticket)
• https://twitter.com/travisci/status/461444701976264705

[He-Pin]

@dwijnand FYI,IDEA 16 EAP is requiring JDK 8 now,then that could be an hint.I really know what are currently talking about. And IDEA 16 still allows you to compile java 1.3 code:)

[mdedetrich]

In my personal opinion, pushing for JDK-8 seems like a great goal. JDK 8 has much better ground support for the features that the Scala community expects (everything from NIO to Future's to Lambda to Java's new DateTime)

For these reasons, JDK 8 has a very good set of foundations which I think would benefit the community enormously.

The only issue of course, is projects like android-sdk-plugin, which only targets JDK 1.7 (because thats the only thing that Google's android toolchain supports). There may be other cases like this

I think the Scala version for SBT isn't that important, however using SBT with Scala 2.12 does provide its benefits, such as producing much smaller jar's (which can have a noticeable impact for big frameworks like Play)

[SethTisue]

we probably want to speak to other tools teams, such as the scalac team

some Scala team folks have already commented above on the general issues here, but I want to respond specifically about the impact on the repositories we maintain:

in most of our repos, we use branches rather than cross-building, so I think it's fine for our 2.11.x branches to stay on sbt 0.13 forever. (and of course all 2.12.x stuff lives in Java 8 land and will be free to move to sbt 1.0 regardless of your decision here.)

some standard modules are still cross-built, e.g. scala-parser-combinators, but others have already moved to a branching strategy, e.g. scala-swing. in the long run, if all of the modules have to end up either 1) branching or 2) staying on sbt 0.13 for as long as we continue to support 2.11.x, I think it’s fine, both of these seem like perfectly viable options.

TL;DR no concerns w/r/t our repos, go ahead and require Java 8 if you like.

[eed3si9n]

sbt 1.0.x will be on JDK 8.

[fommil]

Woohoo!