Packages

  • package root

    This is the documentation for the Scala standard library.

    This is the documentation for the Scala standard library.

    Package structure

    The scala package contains core types like Int, Float, Array or Option which are accessible in all Scala compilation units without explicit qualification or imports.

    Notable packages include:

    Other packages exist. See the complete list on the right.

    Additional parts of the standard library are shipped as separate libraries. These include:

    • scala.reflect - Scala's reflection API (scala-reflect.jar)
    • scala.xml - XML parsing, manipulation, and serialization (scala-xml.jar)
    • scala.swing - A convenient wrapper around Java's GUI framework called Swing (scala-swing.jar)
    • scala.util.parsing - Parser combinators (scala-parser-combinators.jar)

    Automatic imports

    Identifiers in the scala package and the scala.Predef object are always in scope by default.

    Some of these identifiers are type aliases provided as shortcuts to commonly used classes. For example, List is an alias for scala.collection.immutable.List.

    Other aliases refer to classes provided by the underlying platform. For example, on the JVM, String is an alias for java.lang.String.

    Definition Classes
    root
  • package scala

    Core Scala types.

    Core Scala types. They are always available without an explicit import.

    Definition Classes
    root
  • package concurrent

    This package object contains primitives for concurrent and parallel programming.

    This package object contains primitives for concurrent and parallel programming.

    Guide

    A more detailed guide to Futures and Promises, including discussion and examples can be found at http://docs.scala-lang.org/overviews/core/futures.html.

    Common Imports

    When working with Futures, you will often find that importing the whole concurrent package is convenient:

    import scala.concurrent._

    When using things like Futures, it is often required to have an implicit ExecutionContext in scope. The general advice for these implicits are as follows.

    If the code in question is a class or method definition, and no ExecutionContext is available, request one from the caller by adding an implicit parameter list:

    def myMethod(myParam: MyType)(implicit ec: ExecutionContext) = …
    //Or
    class MyClass(myParam: MyType)(implicit ec: ExecutionContext) { … }

    This allows the caller of the method, or creator of the instance of the class, to decide which ExecutionContext should be used.

    For typical REPL usage and experimentation, importing the global ExecutionContext is often desired.

    import scala.concurrent.ExcutionContext.Implicits.global

    Specifying Durations

    Operations often require a duration to be specified. A duration DSL is available to make defining these easier:

    import scala.concurrent.duration._
    val d: Duration = 10.seconds

    Using Futures For Non-blocking Computation

    Basic use of futures is easy with the factory method on Future, which executes a provided function asynchronously, handing you back a future result of that function without blocking the current thread. In order to create the Future you will need either an implicit or explicit ExecutionContext to be provided:

    import scala.concurrent._
    import ExecutionContext.Implicits.global  // implicit execution context
    
    val firstZebra: Future[Int] = Future {
      val source = scala.io.Source.fromFile("/etc/dictionaries-common/words")
      source.toSeq.indexOfSlice("zebra")
    }

    Avoid Blocking

    Although blocking is possible in order to await results (with a mandatory timeout duration):

    import scala.concurrent.duration._
    Await.result(firstZebra, 10.seconds)

    and although this is sometimes necessary to do, in particular for testing purposes, blocking in general is discouraged when working with Futures and concurrency in order to avoid potential deadlocks and improve performance. Instead, use callbacks or combinators to remain in the future domain:

    val animalRange: Future[Int] = for {
      aardvark <- firstAardvark
      zebra <- firstZebra
    } yield zebra - aardvark
    
    animalRange.onSuccess {
      case x if x > 500000 => println("It's a long way from Aardvark to Zebra")
    }
    Definition Classes
    scala
  • package duration
    Definition Classes
    concurrent
  • package forkjoin
    Definition Classes
    concurrent
  • Await
  • Awaitable
  • BlockContext
  • CanAwait
  • Channel
  • DelayedLazyVal
  • ExecutionContext
  • ExecutionContextExecutor
  • ExecutionContextExecutorService
  • Future
  • JavaConversions
  • Lock
  • OnCompleteRunnable
  • Promise
  • SyncChannel
  • SyncVar

trait ExecutionContext extends AnyRef

An ExecutionContext can execute program logic asynchronously, typically but not necessarily on a thread pool.

A general purpose ExecutionContext must be asynchronous in executing any Runnable that is passed into its execute-method. A special purpose ExecutionContext may be synchronous but must only be passed to code that is explicitly safe to be run using a synchronously executing ExecutionContext.

APIs such as Future.onComplete require you to provide a callback and an implicit ExecutionContext. The implicit ExecutionContext will be used to execute the callback.

While it is possible to simply import scala.concurrent.ExecutionContext.Implicits.global to obtain an implicit ExecutionContext, application developers should carefully consider where they want to set execution policy; ideally, one place per application—or per logically related section of code— will make a decision about which ExecutionContext to use. That is, you will mostly want to avoid hardcoding, especially via an import, scala.concurrent.ExecutionContext.Implicits.global. The recommended approach is to add (implicit ec: ExecutionContext) to methods, or class constructor parameters, which need an ExecutionContext.

Then locally import a specific ExecutionContext in one place for the entire application or module, passing it implicitly to individual methods. Alternatively define a local implicit val with the required ExecutionContext.

A custom ExecutionContext may be appropriate to execute code which blocks on IO or performs long-running computations. ExecutionContext.fromExecutorService and ExecutionContext.fromExecutor are good ways to create a custom ExecutionContext.

The intent of ExecutionContext is to lexically scope code execution. That is, each method, class, file, package, or application determines how to run its own code. This avoids issues such as running application callbacks on a thread pool belonging to a networking library. The size of a networking library's thread pool can be safely configured, knowing that only that library's network operations will be affected. Application callback execution can be configured separately.

Annotations
@implicitNotFound( msg = ... )
Source
ExecutionContext.scala
Linear Supertypes
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. ExecutionContext
  2. AnyRef
  3. Any
Implicitly
  1. by any2stringadd
  2. by StringFormat
  3. by Ensuring
  4. by ArrowAssoc
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. All

Abstract Value Members

  1. abstract def execute(runnable: Runnable): Unit

    Runs a block of code on this execution context.

    Runs a block of code on this execution context.

    runnable

    the task to execute

  2. abstract def reportFailure(cause: Throwable): Unit

    Reports that an asynchronous computation failed.

    Reports that an asynchronous computation failed.

    cause

    the cause of the failure

Deprecated Value Members

  1. def prepare(): ExecutionContext

    Prepares for the execution of a task.

    Prepares for the execution of a task. Returns the prepared execution context. The recommended implementation of prepare is to return this.

    This method should no longer be overridden or called. It was originally expected that prepare would be called by all libraries that consume ExecutionContexts, in order to capture thread local context. However, this usage has proven difficult to implement in practice and instead it is now better to avoid using prepare entirely.

    Instead, if an ExecutionContext needs to capture thread local context, it should capture that context when it is constructed, so that it doesn't need any additional preparation later.

    Annotations
    @deprecated
    Deprecated

    (Since version 2.12.0) preparation of ExecutionContexts will be removed