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

Getting Started

gears icon Milestones, nightlies, etc.

list icon All Previous Releases

Current API Docs

list icon API Docs (other versions)

books icon Scala Documentation

books icon Language Specification

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.

Learn More

or visit the Scala Documentation

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

Upcoming Training

What's New

announcement
Scala 2.12.0-RC1 is now available!
date icon Tuesday, September 06, 2016

We are happy to announce the availability of Scala 2.12.0-RC1!

Note, however, that Scala 2.12.0-RC2 will follow, due to known regressions detailed below.

The most notable changes since M5 are:

  • #5135: Either is now right-biased
  • SI-4826: Scaladoc now supports doc comments in Java sources
  • SI-7187: Eta-expansion of zero-argument method values is now deprecated
  • #5307: Reduced interference from SAMs when inferring function types in the presence of overload
  • #5141 / #5294: Refactoring of def, val, and lazy val handling, fixing assorted corner cases and inconsistencies
  • #5311: Scala is now built with sbt instead of Ant (affects only contributors, not users)

In total, we merged 82 pull requests, of which 6 are by new contributors – welcome! This milestone resolves 25 JIRA tickets.

As usual for Scala pre-releases, 2.12.0-RC1 is not binary compatible with any other Scala version, including any 2.12 milestones.

Known issues

As with previous 2.12 builds, the new trait encoding may make some trait-based code run slower. As a result, compile times may also be longer in 2.12 than 2.11. We welcome feedback from the Scala community helping to isolate unusual slowdowns.

The following known regressions will be fixed in 2.12.0-RC2:

  • SD-225 may cause drastically longer compile times for certain kinds of code.
  • SI-9918 may cause scala.reflect.internal.Types$TypeErrors in code involving package objects.
  • SI-9920 may cause java.lang.NoSuchMethodErrors at runtime.
  • A regression may cause java.util.NoSuchElementExceptions in scala.tools.nsc.backend.jvm.BCodeSkelBuilder; see #5395.

Because of the last-mentioned regression, Shapeless will not be published for 2.12.0-RC1.

We hope to address the following in a future 2.12.x release:

  • SI-9824: Parallel collections are prone to deadlock in the REPL and in object initializers.

Scala 2.12

Scala 2.12 requires a Java 8 runtime.

Scala 2.12 is all about making optimal use of Java 8’s new features. Traits (#5003) and functions are compiled to their Java 8 equivalents, and we treat Single Abstract Method types and Scala’s builtin function types uniformly from type checking to the back end (#4971). We also use invokedynamic for a more natural encoding of other language features (#4896). We’ve standardized on the GenBCode back end (#4814, #4838) and the flat classpath implementation is now the default (#5057). The optimizer has been completely overhauled for 2.12.

Except for the breaking changes listed below, code that compiles on 2.11.x without deprecation warnings should compile on 2.12.x too, unless you use experimental APIs such as reflection. If you find incompatibilities, please file an issue.

New features

With this release candidate, we consider 2.12.x to be feature complete.

For 2.12.0, we will try to remain binary compatible with RC1, and we won’t risk regressions except for the most critical bugs.

Trait compiles to an interface

With Java 8 allowing concrete methods in interfaces, Scala 2.12 is able to compile a trait to a single interface. Before, a trait was represented as a class that held the method implementations and an interface. Note that the compiler still has quite a bit of magic to perform behind the scenes, so that care must be taken if a trait is meant to be implemented in Java. (Briefly, if a trait does any of the following its subclasses require synthetic code: defining fields, calling super, initializer statements in the body, extending a class, relying on linearization to find implementations in the right super trait.)

Java 8-style lambdas

Scala 2.12 emits closures in the same style as Java 8, whether they target a FunctionN class from the standard library or a user-defined Single Abstract Method type. The type checker accepts a function literal as a valid expression for either kind of “function-like” type (built-in or SAM). This improves the experience of using libraries written for Java 8 in Scala.

For each lambda the compiler generates a method containing the lambda body, and emits an invokedynamic that will spin up a lightweight class for this closure using the JDK’s LambdaMetaFactory.

Compared to Scala 2.11, the new scheme has the advantage that, in most cases, the compiler does not need to generate an anonymous class for each closure. This leads to significantly smaller JAR files.

New back end

Scala 2.12 standardizes on the “GenBCode” back end, which emits code more quickly because it directly generates ASM bytecode from Scala compiler trees, while the previous back end used an intermediate representation called “ICode”. The old back ends (GenASM and GenIcode) have been removed (#4814, #4838).

New optimizer

The GenBCode back end includes a new inliner and bytecode optimizer. The optimizer is enabled using -opt compiler option, which defaults to -opt:l:classpath. Check -opt:help to see the full list of available options for the optimizer.

The following optimizations are available:

  • Inlining final methods, including methods defined in objects and final methods defined in traits
  • If a closure is allocated and invoked within the same method, the closure invocation is replaced by an invocations of the corresponding lambda body method
  • Dead code elimination and a small number of cleanup optimizations
  • Box/unbox elimination #4858

Either is now right-biased

Either now supports operations like map, flatMap, contains, toOption, and so forth, which operate on the right-hand side.

.left and .right are deprecated in favor of .swap.

The changes are source-compatible with old code (except in the presence of conflicting extension methods).

Thanks, Simon Ochsenreither, for this contribution.

Futures improved

This blog post series by Viktor Klang explores the diverse improvements made to scala.concurrent.Future for 2.12.

Scaladoc now supports doc comments in Java sources

Thanks, Jakob Odersky, for this fix to SI-4826.

Partial unification of type constructors (SI-2712)

Compiling with -Ypartial-unification adds partial unification of type constructors, fixing the notorious SI-2712, thanks to Miles Sabin.

Breaking changes

SAM types

As of #4971, we treat Single Abstract Method types in the same way as our built-in FunctionN classes. This means overloading resolution has more contenders to choose from, making type inference less effective. Here’s an example:

class C[V] {
  def sort(cmp: java.util.Comparator[V]): C[V] = ???
  def sort(cmp: (V, V) => Int): C[V] = sort(
    new java.util.Comparator[V] {
      def compare(a: V, b: V): Int = cmp(a, b)
    })
}

(new C[Int]) sort (_ - _) // error
(new C[Int]) sort ((_ - _): java.util.Comparator[Int]) // ok
(new C[Int]) sort ((a: Int, b: Int) => a - b)  // ok

The first attempt fails because the type checker cannot infer the types for _ - _’s arguments anymore. Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments the methods are applied to. When a function is passed as an argument to an overloaded method, we do this by considering the “shape” of the function (essentially, its arity). Now that Comparator[?] and (?, ?) => ? are both considered functions of arity two, our clever scheme breaks down and the programmer must either select an overload (second application) or make the argument types explicit (last application, which resolves to the Function2 overload).

Finally, implicit conversion of SAM types to Function types won’t kick in anymore, since the compiler does this conversion itself first:

trait MySam { def apply(x: Int): String }

implicit def unused(fun: Int => String): MySam
  = new MySam { def apply(x: Int) = fun(x) }

// uses sam conversion, not the `unused` implicit
val sammy: MySam = _.toString

Inferred types for val (and lazy val)

#5141 and #5294 align type inference for def, val, and lazy val, fixing assorted corner cases and inconsistencies. As a result, the inferred type of a val or lazy val may change.

In particular, implicit vals that didn’t need explicitly declared types before may need them now. (This is always good practice anyway.)

You can get the old behavior with -Xsource:2.11. This may be useful for testing whether these changes are responsible if your code fails to compile.

Changed syntax trees (affects macro and compiler plugin authors)

PR #4794 changed the syntax trees for selections of statically accessible symbols. For example, a selection of Predef no longer has the shape q"scala.this.Predef" but simply q"scala.Predef". Macros and compiler plugins matching on the old tree shape need to be adjusted.

Binary compatibility

Since Scala 2.11, minor releases of Scala are binary compatible with each other. Scala 2.12 will continue this tradition: every 2.12.x release will be binary compatible with 2.12.0. Milestones and release candidates, however, are not binary compatible with any other release.

Scala 2.12 is not and will not be binary compatible with the 2.11.x series. This allows us to keep improving the Scala compiler and standard library. We are working with the community to ensure that core projects in the Scala eco-system become available for 2.12. Please refer to this growing list of libraries and frameworks.

The Scala 2.11.1 release notes explain in more detail on how binary compatibility works in Scala. The same policies apply to 2.12 as well.

Contributors

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.

According to git shortlog -sn --no-merges v2.12.0-M5..v2.12.0-RC1, the following contributors helped to realize this milestone: Adriaan Moors, Jason Zaugg, Lukas Rytz, Stefan Zeiger, A. P. Marki, Simon Ochsenreither, Seth Tisue, Jakob Odersky, Dale Wijnand, Dima Tkach, Janek Bogucki, Michał Pociecha, Christopher Davenport, Martin Olsson, tomjridge, Miles Sabin, Oscar Boykin, Raul Bache, Rex Kerr, Dmitriy Pogretskiy, Daniel Barclay, Antoine Gourlay, Steven Mitchell, Carsten Varming. Thank you!

Release notes

Improvements to these release notes are welcome!

Obtaining Scala

more...

Recently...

Scala 2.12.0-RC1
date-icon Tuesday, September 06, 2016
August SIP Meeting Results: 2 SIPs Rejected and 2 SIPs Updated
date-icon Monday, August 15, 2016 blog
On August 10, the Scala Improvement Process (SIP) Committee held their monthly meeting to discuss and give feedback on four proposals, both new and old....
Scala Library Index Reaches Beta!
date-icon Tuesday, August 09, 2016 blog
Today, the Scala Center team is very proud to announce that The Scala Package Index, or Scaladex for short, has reached beta v1! This means...
date-icon
For more, visit our
News archive or Blog

Scala on Twitter


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


Copyright © 2002- École Polytechnique Fédérale de Lausanne (EPFL)
Lausanne, Switzerland

Scala footer logo