Object-Oriented Meets Functional

Have the best of both worlds. Construct elegant class hierarchies for maximum code reuse and extensibility, implement their behavior using higher-order functions. Or anything in-between.

Learn More

 

Scala began life in 2003, created by Martin Odersky and his research group at EPFL, next to Lake Geneva and the Alps, in Lausanne, Switzerland. Scala has since grown into a mature open source programming language, used by hundreds of thousands of developers, and is developed and maintained by scores of people all over the world.
Download API Docs    
Spiral
Scala
2.11.0

Scala in a Nutshell

 click the boxes below to see Scala in action! 

Seamless Java Interop

Scala runs on the JVM, so Java and Scala stacks can be freely mixed for totally seamless integration.

Type Inference

So the type system doesn’t feel so static. Don’t work for the type system. Let the type system work for you!

Concurrency
& Distribution

Use data-parallel operations on collections, use actors for concurrency and distribution, or futures for asynchronous programming.

Traits

Combine the flexibility of Java-style interfaces with the power of classes. Think principled multiple-inheritance.

Pattern Matching

Think “switch” on steroids. Match against class hierarchies, sequences, and more.

Higher-Order Functions

Functions are first-class objects. Compose them with guaranteed type safety. Use them anywhere, pass them to anything.

Author.scala
class Author(val firstName: String,
    val lastName: String) extends Comparable[Author] {

  override def compareTo(that: Author) = {
    val lastNameComp = this.lastName compareTo that.lastName
    if (lastNameComp != 0) lastNameComp
    else this.firstName compareTo that.firstName
  }
}

object Author {
  def loadAuthorsFromFile(file: java.io.File): List[Author] = ???
}
App.java
import static scala.collection.JavaConversions.asJavaCollection;

public class App {
    public List<Author> loadAuthorsFromFile(File file) {
        return new ArrayList<Author>(asJavaCollection(
            Author.loadAuthorsFromFile(file)));
    }

    public void sortAuthors(List<Author> authors) {
        Collections.sort(authors);
    }

    public void displaySortedAuthors(File file) {
        List<Author> authors = loadAuthorsFromFile(file);
        sortAuthors(authors);
        for (Author author : authors) {
            System.out.println(
                author.lastName() + ", " + author.firstName());
        }
    }
}

Combine Scala and Java seamlessly

Scala classes are ultimately JVM classes. You can create Java objects, call their methods and inherit from Java classes transparently from Scala. Similarly, Java code can reference Scala classes and objects.

In this example, the Scala class Author implements the Java interface Comparable<T> and works with Java Files. The Java code uses a method from the companion object Author, and accesses fields of the Author class. It also uses JavaConversions to convert between Scala collections and Java collections.

Type inference
scala> class Person(val name: String, val age: Int) {
     |   override def toString = s"$name ($age)"
     | }
defined class Person

scala> def underagePeopleNames(persons: List[Person]) = {
     |   for (person <- persons; if person.age < 18)
     |     yield person.name
     | }
underagePeopleNames: (persons: List[Person])List[String]

scala> def createRandomPeople() = {
     |   val names = List("Alice", "Bob", "Carol",
     |       "Dave", "Eve", "Frank")
     |   for (name <- names) yield {
     |     val age = (Random.nextGaussian()*8 + 20).toInt
     |     new Person(name, age)
     |   }
     | }
createRandomPeople: ()List[Person]

scala> val people = createRandomPeople()
people: List[Person] = List(Alice (16), Bob (16), Carol (19), Dave (18), Eve (26), Frank (11))

scala> underagePeopleNames(people)
res1: List[String] = List(Alice, Bob, Frank)

Let the compiler figure out the types for you

The Scala compiler is smart about static types. Most of the time, you need not tell it the types of your variables. Instead, its powerful type inference will figure them out for you.

In this interactive REPL session (Read-Eval-Print-Loop), we define a class and two functions. You can observe that the compiler infers the result types of the functions automatically, as well as all the intermediate values.

Concurrent/Distributed
val x = future { someExpensiveComputation() }
val y = future { someOtherExpensiveComputation() }
val z = for (a <- x; b <- y) yield a*b
for (c <- z) println("Result: " + c)
println("Meanwhile, the main thread goes on!")

Go Concurrent or Distributed with Futures & Promises

In Scala, futures and promises can be used to process data asynchronously, making it easier to parallelize or even distribute your application.

In this example, the future{} construct evaluates its argument asynchronously, and returns a handle to the asynchronous result as a Future[Int]. For-comprehensions can be used to register new callbacks (to post new things to do) when the future is completed, i.e., when the computation is finished. And since all this is executed asynchronously, without blocking, the main program thread can continue doing other work in the meantime.

Traits
abstract class Spacecraft {
  def engage(): Unit
}
trait CommandoBridge extends Spacecraft {
  def engage(): Unit = {
    for (_ <- 1 to 3)
      speedUp()
  }
  def speedUp(): Unit
}
trait PulseEngine extends Spacecraft {
  val maxPulse: Int
  var currentPulse: Int = 0
  def speedUp(): Unit = {
    if (currentPulse < maxPulse)
      currentPulse += 1
  }
}
class StarCruiser extends Spacecraft
                     with CommandoBridge
                     with PulseEngine {
  val maxPulse = 200
}

Flexibly Combine Interface & Behavior

In Scala, multiple traits can be mixed into a class to combine their interface and their behavior.

Here, a StarCruiser is a Spacecraft with a CommandoBridge that knows how to engage the ship (provided a means to speed up) and a PulseEngine that specifies how to speed up.

Pattern matching
// Define a set of case classes for representing binary trees.
sealed abstract class Tree
case class Node(elem: Int, left: Tree, right: Tree) extends Tree
case object Leaf extends Tree

// Return the in-order traversal sequence of a given tree.
def inOrder(t: Tree): List[Int] = t match {
  case Node(e, l, r) => inOrder(l) ::: List(e) ::: inOrder(r)
  case Leaf          => List()
}

Switch on the structure of your data

In Scala, case classes are used to represent structural data types. They implicitly equip the class with meaningful toString, equals and hashCode methods, as well as the ability to be deconstructed with pattern matching.

In this example, we define a small set of case classes that represent binary trees of integers (the generic version is omitted for simplicity here). In inOrder, the match construct chooses the right branch, depending on the type of t, and at the same time deconstructs the arguments of a Node.

Go Functional with Higher-Order Functions

In Scala, functions are values, and can be defined as anonymous functions with a concise syntax.

Scala
val people: Array[Person]

// Partition `people` into two arrays `minors` and `adults`.
// Use the higher-order function `(_.age < 18)` as a predicate for partitioning.
val (minors, adults) = people partition (_.age < 18)
Java
List<Person> people;

List<Person> minors = new ArrayList<Person>(people.size());
List<Person> adults = new ArrayList<Person>(people.size());
for (Person person : people) {
    if (person.getAge() < 18)
        minors.add(person);
    else
        adults.add(person);
}

In the Scala example on the left, the partition method, available on all collection types (including Array), returns two new collections of the same type. Elements from the original collection are partitioned according to a predicate, which is given as a lambda, i.e., an anonymous function. The _ stands for the parameter to the lambda, i.e., the element that is being tested. This particular lambda can also be written as (x => x.age < 18).

The same program is implemented in Java on the right.

Upcoming Events

See more events or add one to our feed

What's New

announcement
date icon Monday, April 21, 2014

We are very pleased to announce the final release of Scala 2.11.0!

There have been no code changes since RC4, just improvements to documentation and version bump to the most recent stable version of Akka actors. Here’s the difference between the release and RC4.

Code that compiled on 2.10.x without deprecation warnings should compile on 2.11.x (we do not guarantee this for experimental APIs, such as reflection). If not, please file a regression. We are working with the community to ensure availability of the core projects of the Scala 2.11.x eco-system, please see below for a list. This release is not binary compatible with the 2.10.x series, to allow us to keep improving the Scala standard library.

The Scala 2.11.x series targets Java 6, with (evolving) experimental support for Java 8. In 2.11.0, Java 8 support is mostly limited to reading Java 8 bytecode and parsing Java 8 source. Stay tuned for more complete (experimental) Java 8 support.

New features in the 2.11 series

This release contains all of the bug fixes and improvements made in the 2.10 series, as well as:

  • Collections

    • Immutable HashMaps and HashSets perform faster filters, unions, and the like, with improved structural sharing (lower memory usage or churn).
    • Mutable LongMap and AnyRefMap have been added to provide improved performance when keys are Long or AnyRef (performance enhancement of up to 4x or 2x respectively).
    • BigDecimal is more explicit about rounding and numeric representations, and better handles very large values without exhausting memory (by avoiding unnecessary conversions to BigInt).
    • List has improved performance on map, flatMap, and collect.
    • See also Deprecation above: we have slated many classes and methods to become final, to clarify which classes are not meant to be subclassed and to facilitate future maintenance and performance improvements.
  • Modularization

    • The core Scala standard library jar has shed 20% of its bytecode. The modules for xml, parsing, swing as well as the (unsupported) continuations plugin and library are available individually or via scala-library-all. Note that this artifact has weaker binary compatibility guarantees than scala-library – as explained above.
    • The compiler has been modularized internally, to separate the presentation compiler, scaladoc and the REPL. We hope this will make it easier to contribute. In this release, all of these modules are still packaged in scala-compiler.jar. We plan to ship them in separate JARs in 2.12.x.
  • Reflection, macros and quasiquotes

    • Please see this detailed changelog that lists all significant changes and provides advice on forward and backward compatibility.
    • See also this summary of the experimental side of the 2.11 development cycle.
    • #3321 introduced Sprinter, a new AST pretty-printing library! Very useful for tools that deal with source code.
  • Back-end

    • The GenBCode back-end (experimental in 2.11). See @magarciaepfl’s extensive documentation.
    • A new experimental way of compiling closures, implemented by @JamesIry. With -Ydelambdafy:method anonymous functions are compiled faster, with a smaller bytecode footprint. This works by keeping the function body as a private (static, if no this reference is needed) method of the enclosing class, and at the last moment during compilation emitting a small anonymous class that extends FunctionN and delegates to it. This sets the scene for a smooth migration to Java 8-style lambdas (not yet implemented).
    • Branch elimination through constant analysis #2214
    • Scala.js, a separate project, provides an experimental JavaScript back-end for Scala 2.11. Note that it is not part of the standard Scala distribution.
    • Be more Avian- friendly.
  • Compiler Performance

    • Incremental compilation has been improved significantly. To try it out, upgrade to sbt 0.13.2 and add incOptions := incOptions.value.withNameHashing(true) to your build! Other build tools are also supported. More info at this sbt issue – that’s where most of the work happened. More features are planned, e.g. class-based tracking.
    • We’ve been optimizing the batch compiler’s performance as well, and will continue to work on this during the 2.11.x cycle.
    • Improve performance of reflection SI-6638
  • The IDE received numerous bug fixes and improvements!

  • REPL

  • Improved -Xlint warnings

    • Warn about unused private / local terms and types, and unused imports.
    • This will even tell you when a local var could be a val.
  • Slimming down the compiler

    • The experimental .NET backend has been removed from the compiler.
    • Scala 2.10 shipped with new implementations of the Pattern Matcher and the Bytecode Emitter. We have removed the old implementations.
    • Search and destroy mission for ~5000 chunks of dead code. #1648

The Scala team and contributors fixed 613 bugs that are exclusive to Scala 2.11.0! We also backported as many as possible. With the release of 2.11, 2.10 backports will be dialed back.

A big thank you to everyone who’s helped improve Scala by reporting bugs, improving our documentation, participating in mailing lists and other public fora, and – of course – submitting and reviewing pull requests! You are all awesome.

Concretely, according to git log --no-merges --oneline master --not 2.10.x --format='%aN' | sort | uniq -c | sort -rn, 112 people contributed code, tests, and/or documentation to Scala 2.11.x: Paul Phillips, Jason Zaugg, Eugene Burmako, Adriaan Moors, Den Shabalin, Simon Ochsenreither, A. P. Marki, Miguel Garcia, James Iry, Iain McGinniss, Rex Kerr, Grzegorz Kossakowski, Vladimir Nikolaev, Eugene Vigdorchik, François Garillot, Mirco Dotta, Rüdiger Klaehn, Raphael Jolly, Kenji Yoshida, Paolo Giarrusso, Antoine Gourlay, Hubert Plociniczak, Aleksandar Prokopec, Simon Schaefer, Lex Spoon, Andrew Phillips, Sébastien Doeraene, Luc Bourlier, Josh Suereth, Jean-Remi Desjardins, Vojin Jovanovic, Vlad Ureche, Viktor Klang, Valerian, Prashant Sharma, Pavel Pavlov, Michael Thorpe, Jan Niehusmann, Heejong Lee, George Leontiev, Daniel C. Sobral, Christoffer Sawicki, yllan, rjfwhite, Volkan Yazıcı, Ruslan Shevchenko, Robin Green, Olivier Blanvillain, Lukas Rytz, James Ward, Iulian Dragos, Ilya Maykov, Eugene Yokota, Erik Osheim, Dan Hopkins, Chris Hodapp, Antonio Cunei, Andriy Polishchuk, Alexander Clare, 杨博, srinivasreddy, secwall, nermin, martijnhoekstra, kurnevsky, jinfu-leng, folone, Yaroslav Klymko, Xusen Yin, Trent Ogren, Tobias Schlatter, Thomas Geier, Stuart Golodetz, Stefan Zeiger, Scott Carey, Samy Dindane, Sagie Davidovich, Runar Bjarnason, Roland Kuhn, Roberto Tyley, Robert Nix, Robert Ladstätter, Rike-Benjamin Schuppner, Rajiv, Philipp Haller, Nada Amin, Mike Morearty, Michael Bayne, Mark Harrah, Luke Cycon, Lee Mighdoll, Konstantin Fedorov, Julio Santos, Julien Richard-Foy, Juha Heljoranta, Johannes Rudolph, Jiawei Li, Jentsch, Jason Swartz, James Roper, Havoc Pennington, Evgeny Kotelnikov, Dmitry Petrashko, Dmitry Bushev, David Hall, Daniel Darabos, Dan Rosen, Cody Allen, Carlo Dapor, Brian McKenna, Andrey Kutejko, Alden Torres.

Thank you all very much.

If you find any errors or omissions in these relates notes, please submit a PR!

Reporting Bugs / Known Issues

Please file any bugs you encounter. If you’re unsure whether something is a bug, please contact the scala-user mailing list.

Before reporting a bug, please have a look at these known issues.

Scala IDE for Eclipse

The Scala IDE with this release built in is available from this update site for Eclipse 4.2/4.3 (Juno/Kepler). Please have a look at the getting started guide for more info.

Available projects

The following Scala projects have already been released against 2.11.0! We’d love to include yours in this list as soon as it’s available – please submit a PR to update these release notes.

"org.scalacheck"                   %% "scalacheck"                % "1.11.3"
"org.scalatest"                    %% "scalatest"                 % "2.1.3"
"org.scalautils"                   %% "scalautils"                % "2.1.3"
"com.typesafe.akka"                %% "akka-actor"                % "2.3.2"
"com.typesafe.scala-logging"       %% "scala-logging-slf4j"       % "2.0.4"
"org.scala-lang.modules"           %% "scala-async"               % "0.9.1"
"org.scalikejdbc"                  %% "scalikejdbc-interpolation" % "2.0.0-beta1"
"com.softwaremill.scalamacrodebug" %% "macros"                    % "0.4"
"com.softwaremill.macwire"         %% "macros"                    % "0.6"
"com.chuusai"                      %% "shapeless"                 % "1.2.4"
"com.chuusai"                      %% "shapeless"                 % "2.0.0"
"org.nalloc"                       %% "optional"                  % "0.1.0"
"org.scalaz"                       %% "scalaz-core"               % "7.0.6"
"com.nocandysw"                    %% "platform-executing"        % "0.5.0"
"com.qifun"                        %% "stateless-future"          % "0.1.1"
"com.github.scopt"                 %% "scopt"                     % "3.2.0"
"com.dongxiguo"                    %% "fastring"                  % "0.2.4"
"com.github.seratch"               %% "ltsv4s"                    % "1.0.0"
"com.googlecode.kiama"             %% "kiama"                     % "1.5.3"
"org.scalamock"                    %% "scalamock-scalatest-support" % "3.0.1"
"org.scalamock"                    %% "scalamock-specs2-support"  % "3.0.1"
"com.github.nscala-time"           %% "nscala-time"               % "1.0.0"
"com.github.xuwei-k"               %% "applybuilder70"            % "0.1.2"
"com.github.xuwei-k"               %% "nobox"                     % "0.1.9"
"org.typelevel"                    %% "scodec-bits"               % "1.0.0"
"org.typelevel"                    %% "scodec-core"               % "1.0.0"
"com.sksamuel.scrimage"            %% "scrimage"                  % "1.3.20"
"net.databinder"                   %% "dispatch-http"             % "0.8.10"
"net.databinder"                   %% "unfiltered"                % "0.7.1"
"io.argonaut"                      %% "argonaut"                  % "6.0.4"
"org.specs2"                       %% "specs2"                    % "2.3.11"
"com.propensive"                   %% "rapture-core"              % "0.9.0"
"com.propensive"                   %% "rapture-json"              % "0.9.1"
"com.propensive"                   %% "rapture-io"                % "0.9.1"
"org.scala-stm"                    %% "scala-stm"                 % "0.7"

The following projects were released against 2.11.0-RC4, with an 2.11 build hopefully following soon:

"org.scalafx"            %% "scalafx"            % "8.0.0-R4"
"org.scalafx"            %% "scalafx"            % "1.0.0-R8"
"org.scalamacros"        %% "paradise"           % "2.0.0-M7"
"com.clarifi"            %% "f0"                 % "1.1.1"
"org.parboiled"          %% "parboiled-scala"    % "1.1.6"
"org.monifu"             %% "monifu"             % "0.4"

Cross-building with sbt 0.13

When cross-building between Scala versions, you often need to vary the versions of your dependencies. In particular, the new scala modules (such as scala-xml) are no longer included in scala-library, so you’ll have to add an explicit dependency on it to use Scala’s xml support.

Here’s how we recommend handling this in sbt 0.13. For the full build and Maven build, see example.

scalaVersion        := "2.11.0"

crossScalaVersions  := Seq("2.11.0", "2.10.3")

// add scala-xml dependency when needed (for Scala 2.11 and newer)
// this mechanism supports cross-version publishing
libraryDependencies := {
  CrossVersion.partialVersion(scalaVersion.value) match {
    case Some((2, scalaMajor)) if scalaMajor >= 11 =>
      libraryDependencies.value :+ "org.scala-lang.modules" %% "scala-xml" % "1.0.1"
    case _ =>
      libraryDependencies.value
  }
}

Important changes

For most cases, code that compiled under 2.10.x without deprecation warnings should not be affected. We’ve verified this by compiling a sizeable number of open source projects.

Changes to the reflection API may cause breakages, but these breakages can be easily fixed in a manner that is source-compatible with Scala 2.10.x. Follow our reflection/macro changelog for detailed instructions.

We’ve decided to fix the following more obscure deviations from specified behavior without deprecating them first.

  • SI-4577 Compile x match { case _ : Foo.type => } to Foo eq x, as specified. It used to be Foo == x (without warning). If that’s what you meant, write case Foo =>.
  • SI-7475 Improvements to access checks, aligned with the spec (see also the linked issues). Most importantly, private members are no longer inherited. Thus, this does not type check: class Foo[T] { private val bar: T = ???; new Foo[String] { bar: String } }, as the bar in bar: String refers to the bar with type T. The Foo[String]’s bar is not inherited, and thus not in scope, in the refinement. (Example from SI-8371, see also SI-8426.)

The following changes were made after a deprecation cycle (Thank you, @soc, for leading the deprecation effort!)

  • SI-6809 Case classes without a parameter list are no longer allowed.
  • SI-7618 Octal number literals no longer supported.

Finally, some notable improvements and bug fixes:

  • SI-7296 Case classes with > 22 parameters are now allowed.
  • SI-3346 Implicit arguments of implicit conversions now guide type inference.
  • SI-6240 Thread safety of reflection API.
  • #3037 Experimental support for SAM synthesis.
  • #2848 Name-based pattern-matching.
  • SI-6169 Infer bounds of Java-defined existential types.
  • SI-6566 Right-hand sides of type aliases are now considered invariant for variance checking.
  • SI-5917 Improve public AST creation facilities.
  • SI-8063 Expose much needed methods in public reflection/macro API.
  • SI-8126 Add -Xsource option (make 2.11 type checker behave like 2.10 where possible).

To catch future changes like this early, you can run the compiler under -Xfuture, which makes it behave like the next major version, where possible, to alert you to upcoming breaking changes.

Deprecations

Deprecation is essential to two of the 2.11.x series’ three themes (faster/smaller/stabler). They make the language and the libraries smaller, and thus easier to use and maintain, which ultimately improves stability. We are very proud of Scala’s first decade, which brought us to where we are, and we are actively working on minimizing the downsides of this legacy, as exemplified by 2.11.x’s focus on deprecation, modularization and infrastructure work.

The following language “warts” have been deprecated:

  • SI-7605 Procedure syntax (only under -Xfuture).
  • SI-5479 DelayedInit. We will continue support for the important extends App idiom. We won’t drop DelayedInit until there’s a replacement for important use cases. (More details and a proposed alternative.)
  • SI-6455 Rewrite of .withFilter to .filter: you must implement withFilter to be compatible with for-comprehensions.
  • SI-8035 Automatic insertion of () on missing argument lists.
  • SI-6675 Auto-tupling in patterns.
  • SI-7247 NotNull, which was never fully implemented – slated for removal in 2.12.
  • SI-1503 Unsound type assumption for stable identifier and literal patterns.
  • SI-7629 View bounds (under -Xfuture).

We’d like to emphasize the following library deprecations:

  • #3103, #3191, #3582 Collection classes and methods that are (very) difficult to extend safely have been slated for being marked final. Proxies and wrappers that were not adequately implemented or kept up-to-date have been deprecated, along with other minor inconsistencies.
  • scala-actors is now deprecated and will be removed in 2.12; please follow the steps in the Actors Migration Guide to port to Akka Actors
  • SI-7958 Deprecate scala.concurrent.future and scala.concurrent.promise
  • SI-3235 Deprecate round on Int and Long (#3581).
  • We are looking for maintainers to take over the following modules: scala-swing, scala-continuations. 2.12 will not include them if no new maintainer is found. We will likely keep maintaining the other modules (scala-xml, scala-parser-combinators), but help is still greatly appreciated.

Deprecation is closely linked to source and binary compatibility. We say two versions are source compatible when they compile the same programs with the same results. Deprecation requires qualifying this statement: “assuming there are no deprecation warnings”. This is what allows us to evolve the Scala platform and keep it healthy. We move slowly to guarantee smooth upgrades, but we want to keep improving as well!

Binary Compatibility

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. We strive to maintain a similar invariant for the behavior (as opposed to just linkage) of the standard library, but this is not checked mechanically (Scala is not a proof assistant so this is out of reach for its type system).

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).

These are strict constraints, but they have worked well for us in the Scala 2.10.x series. They didn’t stop us from fixing 372 issues in the 2.10.x series post 2.10.0. The advantages are clear, so we will maintain this policy in the 2.11.x series, and are looking (but not yet commiting!) to extend it to include major versions in the future.

Meta

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.

Concretely

Just like the 2.10.x series, we guarantee forwards and backwards compatibility of the "org.scala-lang" % "scala-library" % "2.11.x" and "org.scala-lang" % "scala-reflect" % "2.11.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.concurrent.impl and scala.reflect.runtime, though we will only break compatibility for severe bugs here.

Note that we will only enforce backwards binary compatibility for the new modules (artifacts under the groupId org.scala-lang.modules). As they are opt-in, it’s less of a burden to require having the latest version on the classpath. (Without forward compatibility, the latest version of the artifact must be on the run-time classpath to avoid linkage errors.)

Finally, Scala 2.11.0 introduces scala-library-all to aggregate the modules that constitute a Scala release. Note that this means it does not provide forward binary compatibility, whereas the core scala-library artifact does. We consider the versions of the modules that "scala-library-all" % "2.11.x" depends on to be the canonical ones, that are part of the official Scala distribution. (The distribution itself is defined by the new scala-dist maven artifact.)

License clarification

Scala is now distributed under the standard 3-clause BSD license. Originally, the same 3-clause BSD license was adopted, but slightly reworded over the years, and the “Scala License” was born. We’re now back to the standard formulation to avoid confusion.

Recently...

date-icon Tuesday, April 08, 2014 announcement
We are very pleased to announce Scala 2.11.0-RC4, the next release candidate of Scala 2.11.0! Download it now from scala-lang.org or via Maven Central. Since...
date-icon Monday, March 24, 2014 announcement
We are very happy to announce the final release of Scala 2.10.4! The release is available for download from scala-lang.org or from Maven Central. The...
date-icon Thursday, March 20, 2014 announcement
We are very pleased to announce Scala 2.11.0-RC3, the second (sic) release candidate of Scala 2.11.0! Download it now from scala-lang.org or via Maven Central....
date-icon
For more, visit our
News archive or Blog

Scala on Twitter


 
See more tweets, or
Follow Scala on Twitter
white Twitter logo