Blog

July 1, 2014

Scala 2.12 Road Map

@adriaanm
July 1, 2014
Scala

Yesterday, the Scala 2.12 roadmap was published on scala-lang.org, so we wanted to spread the good word. Below are the details.

Since Scala 2.12 will require Java 8, here’s how we plan to make this transition as smooth as possible.

Goals

  • Minimize overhead of the transition for both users and library maintainers.
  • Continue Java 6 support for a while longer (only in Scala 2.11).
  • Track the Java platform evolution.

How

  • Upcoming 2.11.x releases will introduce the following experimental features (under a flag): Java 8-style closure compilation, Miguel’s new back-end & optimizer.
  • Hassle-free cross-building between 2.11 and 2.12 through full backward source compatibility (we won’t remove deprecated methods, but will support optional deprecation errors). Closely align 2.11 and 2.12 compiler and standard library code bases.
  • The official Scala 2.12 distribution will be built for Java 8 (and thus require it). The new back-end (and optimizer) will become the default.

Background

  • We can’t have one Scala binary version target two different Java versions without further artifactId name mangling. Even if maven did have support for specifying the required Java version, this fork would be a big burden on the eco-system. Thus, the split between required Java versions has to align with the Scala (binary) version.
  • We’ll check 2.11/2.12 cross-building by running the same community build on both versions. To improve backwards source compatibility, Scala 2.12 will not remove deprecated members. The 2.12 compiler will however (by default) emit deprecation errors for usage of members deprecated <= 2.11.0. (In principle, if we were to compile the 2.12 library for Java 6, it should be backwards binary compatible with 2.11.)
  • It’s important to keep up with the platform, even though Java 8’s MethodHandle-based support for closures may not immediately yield significant performance benefits (definitely reduces bytecode size, and thus likely compilation times, though). For platforms that don’t support Java 8 bytecode yet, two projects exist that rewrite Java 8 invokedynamic bytecode to Java 6 (retrolambda or Forax’s JSR292 backport). I’m not aware of the equivalent for default methods, but it’s feasible.

Shared features between Scala 2.11 (under a flag) & 2.12

  • Compile lambdas efficiently using method handles. (Separate compatibility module needed on 2.11 – see below.)
  • Java 8 interop (bidirectional):
    • Improve support for reading Java 8 bytecode (already in 2.11)
    • Improve and turn on SAM support by default (synthesize anonymous class java 8-style). This allows calling Java 8 higher-order methods seamlessly from Scala (already in 2.11 under -Xexperimental).
    • Compatibility module to let Java 8 call Scala higher-order methods.
  • Fully integrate Miguel’s new back-end & optimizer (refactor code, test & document in-depth, remove old back-end).
  • Style checker: an efficient, community-driven, platform for accurate coding style checking (built on top of the compiler).
  • Collections: improve test coverage, performance, documentation (& modularize?)
  • Improve documentation: focus on content. (This is a great place to start contributing, as well as on the tooling side of documentation.)
  • Continue infrastructure improvements (sbt build, improve pull request validation & release automation, bug tracker cleanup and automation).

Features exclusive to Scala 2.12: more Java 8 fun

Development of the following features starts in 2015. Since they are binary incompatible, they can’t be backported to 2.11.

  • Turn FunctionN into Functional Interfaces, so that Java 8 code can call higher-order methods in Scala without a wrapper.
  • Support for @interface traits, which are guaranteed to compile to Java interfaces (useful for interop, performance and binary compatibility). This is a generalization of the above feature.
  • Streams: integrate into Scala collections? (Anywhere from providing converters to replacing existing functionality.)
  • Use the JDK’s forkjoin library instead of embedding our own. (Switch the global default ExecutionContext to be backed by the ForkJoinPool.commonPool().)
  • SIP-20 Improved lazy val initialization (if time allows).

Timing

Scala 2.10.5 (Q4 2014) will be the last 2.10 release. We’re planning five 2.11.x releases in 2014, and a few more in 2015 (we’re still deciding on when to EOL 2.11.x). At Typesafe, 2.12 development will begin with infrastructure work in Q4 2014, with our development focus shifting to 2.12 in 2015.

     

2.10.0

04/01/2013

First 2.10.x release

2.11.0

16/04/2014

First 2.11.x release

2.11.1

19/05/2014

 

2.11.2

21/07/2014

 

2.11.3

29/09/2014

 

2.10.5

Q4 2014

Last 2.10.x release

2.12.0-M1

24/11/2014

 

2.11.4

Dec 2014

 

2.12.0-M{2,3,4}

Q{1,2,3} 2015

quarterly 2.12.0-Mx releases

2.12.0-M5

Oct 2015

 

2.12.0-RC1

Nov 2015

(1 year after M1)

2.12.0

Jan 2016

 

During the development of Scala 2.11, we’ve made big steps forward in automating our release process and regression testing via our Community Build which builds 1M LOC of popular open source projects. Both the release script and the community builds are also run on a nightly basis.

As such, as of Scala 2.11.1, we’ve decided to skip Release Candidates for 2.x.y releases where y > 0. This enables more frequent minor releases on a predictable schedule.

comments powered by Disqus
Browse Recent Blog Posts