Tuesday 5 May 2015
We are very pleased to announce the release of Scala 2.12.0-M1!
Code that compiles on 2.11.x without deprecation warnings should compile on 2.12.x (we do not guarantee this for experimental APIs, such as reflection). If not, please file an issue.
We are working with the community to ensure availability of the core projects of the Scala 2.12 eco-system. This release is not binary compatible with the 2.11.x series, to allow us to keep improving the Scala standard library.
The Scala 2.12 series targets Java 8. Programs written in Scala 2.12, including the Scala 2.12 compiler, can only be executed on Java 8 or newer. Note that the current milestone release (2.12.0-M1) still targets Java 6.
New Features in the 2.12 Series
Scala 2.12 contains all of the bug fixes and improvements made in the 2.11 series.
At the current stage in the milestone cycle, Scala 2.12 is still very similar to Scala 2.11.
The following changes are planned for Scala 2.12:
- Java 8 style closures. The Scala compiler will emit closure classes (lambdas) in the same manner as Java 8. The design notes for this feature are available in this gist.
- Lambda syntax for SAM types.
Similar to Java 8, Scala 2.12 allows instantiating any type with one single abstract method by passing a lambda.
This feature is already avalable in Scala 2.11 using the
-Xexperimentalcompiler option. It improves the experience of using libraries written for Java 8 in Scala.
- New backend and optimizer.
The “GenBCode” backend, which is already available in Scala 2.11 using the
-Ybackend:GenBCodecompiler option, will be enabled by default. Scala 2.12 will also ship with a new inliner and bytecode optimizer. We keep track of issues and work items for the new optimizer on the scala-opt repository issue tracker.
The above list is incomplete and will be extended during the Scala 2.12 milestone cycle.
Up the current milestone, the Scala team and contributors fixed 47 bugs that are exclusive to Scala 2.12.0. During the development cycle of Scala 2.12, we will continue to backport issues to 2.11 whenever feasible. With the release of 2.12.0, backports to 2.11 will be dialed back.
The following modules have been removed from the Scala 2.12 distribution:
- The Scala actors library is no longer released with Scala 2.12. We recommend that you use the Akka actors library instead.
- The Scala distribution archives and the
scala-library-allmaven dependency no longer inlcude Akka actors. To use the Akka actors library, add it to your project as a dependency.
- The continuations plugin is no longer shipped with the Scala 2.12 distribution.
A big thank you to everyone who’s helped improve Scala by reporting bugs, improving our documentation, spreading kindness in mailing lists and other public fora, and submitting and reviewing pull requests! You are all magnificent.
git shortlog -sn --no-merges 2.11.x..v2.12.0-M1, 33 people contributed to this major release:
Jason Zaugg, Lukas Rytz, A. P. Marki, Rex Kerr, Kato Kazuyoshi, Max Bileschi, jxcoder, François Garillot, rubyu, Adriaan Moors, Dominik Gruntz, Evgeny Vereshchagin, Marc Siegel, Masato Sogame, Simon Ochsenreither, Todd Vierling, Viktor Klang, cchantep, Denton Cockburn, Paolo Giarrusso, Denis Rosset, Roman Hargrave, Rui Gonçalves, Shadaj, harryhuk, Steven Scott, Antoine Gourlay, Aleksandar Prokopec, Lukas Elmer, Erlend Hamnaberg, Maks Atygaev, Malte Isberner, dgruntz.
These release notes are hosted on GitHub and are continuously updated during the Scala 2.12.0 release cycle. You are kindly invited to contribute!
Please file any bugs you encounter on our issue tracker. If you’re unsure whether something is a bug, please contact the scala-user mailing list. Before creating a new issue, search search the issue tracker to see if your bug has already been reported.
Scala IDE for Eclipse
A release of the Scala IDE for Eclipse for Scala 2.12 will be available together with the release.
Note that for the current milestone (2.12.0-M1), the Scala IDE is not yet available.
Please refer to the list of libraries and frameworks available for Scala 2.12.
Since Sala 2.11, minor releases of Scala are binary compatible. Scala 2.12 continues this tradition: every 2.12.x release will be binary compatible with 2.12.0. Note that milestone releases and release candidates are not binary compatible with any other release.
When two versions of Scala are binary compatible, it is safe to compile your project on one Scala version and link against another Scala version at run time.
Safe run-time linkage (only!) means that the JVM does not throw a (subclass of)
LinkageError when executing your program in the mixed scenario, assuming that none arise when compiling and running on the same version of Scala.
Concretely, this means you may have external dependencies on your run-time classpath that use a different version of Scala than the one you’re compiling with, as long as they’re binary compatibile.
In other words, separate compilation on different binary compatible versions does not introduce problems compared to compiling and running everything on the same version of Scala.
We check binary compatibility automatically with MiMa.
Forwards and Back
We distinguish forwards and backwards compatibility (think of these as properties of a sequence of versions, not of an individual version). Maintaining backwards compatibility means code compiled on an older version will link with code compiled with newer ones. Forwards compatibility allows you to compile on new versions and run on older ones.
Thus, backwards compatibility precludes the removal of (non-private) methods, as older versions could call them, not knowing they would be removed, whereas forwards compatibility disallows adding new (non-private) methods, because newer programs may come to depend on them, which would prevent them from running on older versions (private methods are exempted here as well, as their definition and call sites must be in the same compilation unit).
Note that so far we’ve only talked about the jars generated by scalac for the standard library and reflection. Our policies do not extend to the meta-issue: ensuring binary compatibility for bytecode generated from identical sources, by different version of scalac? (The same problem exists for compiling on different JDKs.) While we strive to achieve this, it’s not something we can test in general. Notable examples where we know meta-binary compatibility is hard to achieve: specialisation and the optimizer.
In short, if binary compatibility of your library is important to you, use MiMa to verify compatibility before releasing. Compiling identical sources with different versions of the Scala compiler (or on different JVM versions!) could result in binary incompatible bytecode. This is rare, and we try to avoid it, but we can’t guarantee it will never happen.
We guarantee forwards and backwards compatibility of the
"org.scala-lang" % "scala-library" % "2.12.x" and
"org.scala-lang" % "scala-reflect" % "2.12.x" artifacts, except for anything under the
scala.reflect.internal package, as scala-reflect is still experimental.
We also strongly discourage relying on the stability of
scala.reflect.runtime, though we will only break compatibility for severe bugs here.