The Scala Programming Language

Scala 3.9 LTS released!

2026-09-03T00:00:00+02:00

Scala 3.9 LTS released!

We are happy to announce Scala 3.9.0, opening the new Long Term Support line for Scala 3. It succeeds Scala 3.3 LTS as the recommended baseline for library authors and conservative production users, while keeping the Scala Next line available for teams that want the latest language work as soon as it is released.

What does LTS mean?

Scala 3 follows the Scala LTS and Scala Next model. Scala Next receives regular minor releases with new language features, tooling work, and ecosystem changes. Scala LTS receives patch releases focused on bug fixes, diagnostics, tooling improvements, and carefully selected quality-of-life changes that are also subject to the compatibility guarantees of the LTS line.

Libraries published with Scala 3.9 LTS can be consumed by later 3.9 patch releases and by Scala Next. The 3.9 line is expected to receive patches and backports for an extended period.

Library maintainers: artifacts built with Scala 3.9 cannot be consumed by Scala 3.3 projects, so treat the move from Scala 3.3 LTS to Scala 3.9 LTS as a minor-version publishing decision for your own libraries.

Looking back at Scala 3.3 LTS

Scala 3.3.0 was released in May 2023 and became the first Scala 3 LTS. It carried the ecosystem through more than three years of Scala 3 development while Scala Next delivered new syntax, new standard-library work, new tooling integration, and deeper compatibility testing.

The 3.3 LTS line was not a frozen branch. As I write this, 1,420 of 2,380 pull requests merged into the main Scala 3 compiler branch since 3.4.0 were also backported to Scala 3.3 LTS. That’s almost 43% of all changes! That work kept 3.3 useful as a publishing target while still protecting the compatibility expectations that made it attractive in the first place. The result of this decision is visible in the ecosystem - roughly 56% of Scala 3 libraries are currently published using Scala 3.3 LTS.

What’s more, the next patch release - Scala 3.3.9 - is planned within the next month, and Scala 3.3 LTS will remain actively maintained for one year after Scala 3.9.0. However, the number of future backports is expected to be lower than before, as Scala 3.3 LTS and Scala Next codebases have naturally diverged after several years of development. Special thanks go to Paweł Marks, Wojciech Mazur, and Tomasz Godzik from VirtusLab for the sustained backporting and maintenance work over the years!

What’s new in Scala 3.9?

Scala 3.9.0 is both a new LTS baseline and a regular Scala release. It consolidates the changes since Scala 3.8, stabilises one language feature, and includes a broad set of compiler, standard-library, documentation, and tooling fixes.

SIP-71: Allow fully implicit conversions in Scala 3 with `into` - now stable

The into mechanism lets API authors mark selected parameters or types as accepting implicit conversions, without asking all users to enable implicit conversions globally.

This is useful for APIs where conversion is part of the intended design, but where unrestricted implicit conversions would be too broad. Scala 3.8 introduced into as a preview feature; Scala 3.9 makes it part of the stable language.

//> using scala 3.9

// Prefer `into` as a soft modifier when you control the conversion target.
into trait IntoIterableOnce[A] extends IterableOnce[A]

def appendAll[A](xs: List[A], ys: IntoIterableOnce[A]): List[A] =
  xs ++ ys

// Use `into[T]` when you can't change the target type definition.
def prependAll[A](xs: Conversion.into[IterableOnce[A]], ys: List[A]): List[A] =
  xs.iterator.toList ++ ys

given [A]: Conversion[Array[A], IntoIterableOnce[A]] = arr =>
  new IntoIterableOnce[A]:
    def iterator: Iterator[A] = arr.iterator

given [A]: Conversion[Array[A], IterableOnce[A]] = _.iterator

val appended = appendAll(List(1, 2), Array(3, 4))
val prepended = prependAll(Array(1, 2), List(3, 4))

Documentation snippets can declare the errors they expect

Scaladoc can compile the code snippets it finds in documentation, which stops examples from quietly rotting as a project changes. Scala 3.9 allows a snippet to also declare the errors and warnings it is meant to produce, on the exact lines where they belong.

Documentation for a library with compile-time constraints often needs to show code that must not compile: a macro reporting a custom error, an API enforcing capability or capture requirements, or a type-level constraint being violated. Until now such a snippet could only claim that it failed somewhere. There was no way to say which line should fail, or whether to expect an error or a warning.

To switch the checks on, add the new test modifier to Scaladoc’s -snippet-compiler setting for the path you want covered:

Compile / doc / scalacOptions += "-snippet-compiler:docs/my-page.md=compile+test"

The path is matched as a prefix, so it can just as well name a directory and cover a whole section of a site at once. Expected diagnostics are then marked in the snippet itself, by putting an // error comment on the line that should fail:

```scala
def sum(xs: List[Int]): Int = xs.sum

sum(List("1", "2")) // error: List[String] is not a List[Int]
```

The rules are:

A marker is matched on severity and line number only. The text following it is not checked, so it can carry an explanation for readers.
// warn checks warnings the same way.
Every diagnostic must be accounted for: an unmarked error or warning fails the run, and a snippet with no markers must compile cleanly.

Snippets in Scaladoc comments are configured through the same path-based setting and honour the markers as well, but the intended use is documentation pages. Snippets in comments written with the legacy wiki syntax are not checked at all, as before.

Scala CLI updates

Scala 3.9 updates Scala CLI, which brings new features:

The REPL can start JShell, so a project’s classpath can be explored from Java as well as from Scala. Try it with scala repl --jshell.
Tests can be written against JUnit 5 (Jupiter), not only the JUnit 4 interface shipped previously.
export can target sbt 2.x, allowing rapid conversion of a project to sbt.
WebAssembly is supported experimentally, matching the new Scala.js backend.
Ammonite support has been dropped.

The most consequential change for anyone moving to a recent JDK is experimental built-in support for Sloth. Code compiled with Scala 3.0 to 3.7 emits lazy val bytecode that goes through the legacy scala.runtime.LazyVals API. That API is implemented with sun.misc.Unsafe, which was terminally deprecated in JDK 24. Under JDK 26 it only prints a warning at runtime; once it is removed in a future JDK, the affected code stops working altogether. Compiling with Scala 3.8 or later is not enough to escape this, because any dependency published with the old lazy vals brings the problem back.

Sloth removes that risk by rewriting the bytecode of such dependencies to the VarHandle-based implementation introduced in Scala 3.8. It can run ahead of time, as a post-processing step over the classpath, or just in time through a dedicated JVM agent.

Both modes are opt-in, and the easiest way to reach for them is a using directive:

//> using dep com.example::library-built-with-scala-3.3:1.0.0
//> using jvm 26
//> using sloth

@main def run(): Unit = println(Legacy.greeting)

Writing //> using slothAgent instead of //> using sloth rewrites each class as it is loaded rather than patching the classpath up front, which is the more practical choice when running tests.

The same options are available on the Scala runner, as --sloth and --sloth-agent. In both cases the feature is experimental, so it has to be unlocked with --power:

scala --power run Main.scala --sloth

See the Scala CLI v1.15.0 and v1.16.0 release notes for the full list of changes.

The parser for Scala CLI using directives has moved into a compiler module org.scala-lang::scala3-directives-parser:3.9.0. This gives tools a shared implementation for parsing build and dependency directives in Scala source files and allows custom use outside of Scala CLI.

Scala.js 1.22

Scala 3.9 ships with Scala.js 1.22.0. The Scala.js backend is part of the compiler rather than a separate plugin, so this Scala.js minor is fixed for the whole 3.9 LTS line: a newer Scala.js minor needs a newer Scala minor. Worth keeping in mind when upgrading: Scala.js 1.22 becomes the minimum version your downstream users need as well.

The main feature of Scala.js 1.22 is a stable WebAssembly backend. It targets a JavaScript host rather than standalone WebAssembly, so the output runs on Node.js, Deno, Bun, or a browser - not on a Wasm-only runtime. It requires ECMAScript 2022 or newer, an engine implementing Wasm 3.0, and the ESModule module kind. Those requirements are now the default Scala.js baseline. Node.js 25, Chrome 137, Firefox 134, and Safari 26 all meet them.

Enable it in sbt by requesting ES modules, ECMAScript 2022, and ESFeatures.withUseWebAssembly:

// build.sbt
scalaJSLinkerConfig := {
  scalaJSLinkerConfig.value
    .withModuleKind(ModuleKind.ESModule)
    .withESFeatures(_.withESVersion(ESVersion.ES2022).withUseWebAssembly(true))
}

The equivalent for Scala CLI is two directives:

//> using wasm
//> using jsModuleKind es

@main def hello(): Unit = println("Hello from Wasm!")

Wasm support in the Scala runner is experimental, so it has to be invoked with --power:

scala --power run HelloWasm.scala

js.async and js.await need one more step on Wasm: enable .withWasmFeatures(_.withUseJSPI(true)) and run on an engine that supports JavaScript Promise Integration. JSPI is standardised, but it is not part of Wasm 3.0, which is why it stays behind that opt-in.

Other improvements in Scala.js 1.22:

Generated code is smaller: the embedded Unicode database uses a tighter encoding, and the JavaScript backend now aggressively optimises arrays of numeric literals.
Unicode support moved to Unicode 15.0, matching JDK 21. It now also accounts for contributory properties, so isLowerCase is true for characters carrying Other_Lowercase, not only for those in the Ll category.
sbt 2.x: if you are migrating, you will need this Scala.js version as well, since sbt-scalajs is now published for sbt 2.x alongside sbt 1.x.

See the Scala.js 1.22.0 announcement for the full list, including bug fixes.

Inaccessible companion implicits will no longer be found in Scala 3.10

When implicit search builds the implicit scope for a type, it looks into that type’s companion object. Until now it did so even when the companion could not be referenced from the call site. That gave call sites unexpected access to private implicits: the instance could be summoned implicitly, even though writing it out explicitly would not compile. Scala 3.9 reports every such resolution as a warning under the -deprecation flag, and Scala 3.10 stops finding those instances altogether.

object api:
  class Config
  private object Config:
    given Config = new Config

  def describe(using Config): String = "configured"

api.describe
// deprecation warning: usage of the implicit defined in object Config, which is not accessible
// here; in Scala 3.10 this implicit will no longer be found

The specification has always required an eligible implicit to be accessible at the point of the call, so this closes a hole rather than removing a feature.

It is worth acting on now. Scala 3.9 only warns, but on 3.10 the same code fails to compile, and you usually cannot fix it in the consuming project: the instance lives in a library, so that library needs a new release to make it accessible. The Open Community Build found around 20 projects that stop compiling on 3.10 for this reason.

What to do: compile with -deprecation on Scala 3.9 to see these warnings in detail. If a library you maintain emits them, publish the fix before 3.10 arrives.

Other notable changes

Java generic signatures are more accurate, covering higher-kinded types, refined types, arrays of value classes, context functions, inherited inner classes, trait setters, and generic using parameters.
The standard-library JAR again declares Automatic-Module-Name in its manifest, which JPMS consumers need.
The standard library is now optimized with the Scala backend optimizer.
Scoverage instrumentation is more reliable, including around separation checking, tail recursion and infinite-loop warnings, constructor applications, singleton types, closures, and parameterless methods.
Incremental compilation can now invalidate type arguments used in macro calls, so Zinc rebuilds those call sites when the argument types change.
Diagnostics and linting are tighter: reports about missing members are more actionable, unused-variable warnings have fewer false positives, and easily misread syntax now warns, such as a template left empty after a trailing colon.
Scaladoc is lighter: it no longer ships jQuery or custom fonts reducing size of published artifacts.

The full list is in the Scala 3.9.0 release notes.

Coming from Scala 3.3 LTS?

If you are moving directly from Scala 3.3 LTS to Scala 3.9 LTS, you are crossing five minor releases. Most projects should still be able to migrate with little or no source work, but it is useful to know what changed along the way. The sections below summarise the most important changes in each minor.

Scala 3.4

New stable features

SIP-53 Quote Pattern Type Variable Syntax - type patterns in quotes became more expressive, so case '[ (t, t, t) ] matches a 3-element tuple whose elements all have the same type.
SIP-54 Multi-Source Extension Overloads - extension methods with the same name can be imported from different sources.
SIP-56 Match Types Specification - match types are properly specified and behave predictably.

Breaking changes

SIP-56 Match Types Specification - some previously accepted match types are no longer legal and need to be rewritten.
Legacy syntax started warning: _ type wildcards, private[this], var x = _, with as a type operator, xs: _* varargs, and a trailing _ to force eta expansion. -rewrite -source:3.4-migration applies every rewrite, and -source:3.3 silences the warnings instead.
Refutable patterns in a for generator now need an explicit case, and .withFilter is no longer inserted without it.
Type inference changed for inline methods, which can break call sites.

Other notable changes

Inference for fold-like calls improved, so xs.foldRight((Nil, Nil))(...) no longer needs explicit types.
Polymorphic lambdas can omit their parameter types when those are inferable from the context.
The compiler no longer synthesizes given definitions that can cycle back to themselves.
Polymorphic lambdas compile to JVM lambdas instead of anonymous classes.
The JVM backend gained the parallelization ported from Scala 2.
Errors for incompatible TASTy versions and broken class files became readable and actionable.
Diagnostics, including unused warnings, are exported to SemanticDB.

Scala 3.5

Notable changes

The scala command itself became the Scala runner, implemented by Scala CLI, so it now compiles, runs, tests, and packages single-module projects.
Experimental best-effort compilation emits BETASTy for code that does not compile, which keeps IDE features working while you type.
Pipelined builds are supported, enabled in sbt with ThisBuild / usePipelining := true.
var members are allowed in type refinements, as in type A = { var number: Int }.
Integer literals can be written in base 2, as in 0b1000_0010.

Scala 3.6

New stable features

SIP-47 Clause Interleaving - type and term parameter clauses can be interleaved, which helps path-dependent APIs.
SIP-56 Match Types Specification - match type extractors follow aliases and singleton types.
SIP-64 Improve Syntax for Context Bounds and Givens - the new context-bound and given syntax, including abstract context bounds on type members.

Breaking changes

Context bounds desugar to using parameters instead of implicit ones. This can shift implicit resolution, and it affects macros or compiler plugins that inspect argument lists by flag.
Java-defined annotations with more than one parameter require named arguments. -source:3.6-migration -rewrite inserts the names on a best-effort basis.
Code whose meaning differs under the upcoming given prioritization began to warn, while still compiling under the old rules.

Scala 3.7

New stable features

SIP-52 Binary APIs - @publicInBinary keeps inline methods binary compatible without generating unstable accessors.
SIP-58 Named Tuples - tuples with named elements, which also allow matching a subset of case-class fields by name and computing structural types without macros.

Breaking changes

Given search now picks the most general matching instance instead of the most specific one. -source:3.5 keeps the old rules and -source:3.7-migration warns where the two differ; see Upcoming Changes to Givens in Scala 3.7.
Passing an explicit argument to an implicit parameter warns unless the call site says using. -rewrite -source:3.7-migration inserts it.
The standard library moved to 2.13.16, where .tail and .init on the empty string throw instead of returning it.

Other notable changes

The expression compiler behind Metals and IntelliJ debugging moved into the compiler repository.
-Wunused was rewritten to produce far fewer false positives, and -Wconf gained origin-based filtering.
Scala 3 was unblocked on Android by boxing SAM return types the Android runtime rejects.
Case classes may have dependent fields, as in case class ConfigEntry(option: Setting, default: option.Value).
The REPL can pull in dependencies at runtime with :jar.
Experimental SIP-61 Unroll Default Arguments for Binary Compatibility - @unroll lets you add default parameters without breaking binary compatibility.
Experimental SIP-68 Referenceable Package Objects - package objects became referenceable as values.

Scala 3.8

New stable features

SIP-57 Replace non-sensical @unchecked annotations - runtimeChecked replaces awkward : @unchecked ascriptions.
SIP-62 For Comprehension Improvements - Better Fors is now enabled by default, which allows aliases before generators and drops redundant map calls.

Breaking changes

JDK 17 or newer is required to compile and run.
The REPL moved into a separate scala3-repl artifact, which embedding tools must depend on explicitly.
The standard library is compiled with Scala 3, so its context bounds desugar to given and explicit arguments need using, as in Array.empty(using ClassTag.Int). Running 3.7.4 with -source:3.7-migration -rewrite fixes most call sites before the bump.
This is the boundary where Scala 2.13’s -Ytasty-reader stops consuming Scala 3 artifacts.
scala-reflect used by Scala 2.13 dependencies on the classpath may no longer work: initialising scala.reflect.runtime.universe against the Scala 3 standard library can fail at runtime. Apache Spark is the best-known case. Details are in the migration guide.

Other notable changes

The REPL pretty-prints results with fansi and pprint, so long values no longer dump as a single unreadable line.
The JVM backend gained the Scala 2 bytecode optimizer in 3.8.3. It is opt-in: -opt enables local optimizations, and -opt-inline:... controls inlining across call sites. See the 3.8.3 release notes and the optimizer documentation.
Lazy vals are implemented with VarHandle instead of sun.misc.Unsafe, which is how Scala 3.8 can run on JDK 24 and later.
Nightly builds moved to repo.scala-lang.org.
Experimental SIP-67 Strict Equality Pattern Matching.
Experimental SIP-70 Flexible Varargs.
Experimental SIP-75 Allow single-line lambdas after :.
Experimental match sub-cases (#23786).

Migration guide

For a practical overview of the migration work behind this release, watch Migration Without Tears: 2,000 Projects, One New LTS.

The Open Community Build results shown there are encouraging: about 1,780 of nearly 2,000 projects build on Scala 3.9 with no or minimal changes, mostly thanks to the compiler’s built-in rewrites.

Recommended upgrade order

A newer compiler should still compile against the libraries you already use. A newer library may require a newer compiler, so do not bump dependencies first.

Upgrade in this order, and let CI pass and commit after each step:

Upgrade the build tool if required.
Move to JDK 17 or later, while staying on the current Scala version where possible.
Upgrade Scala.js if the project uses it.
Upgrade Scala, including the compiler rewrites below. If you use separate Scala version stepping stones, commit each one.
Upgrade libraries after the Scala bump.

For many projects, the migration is just the JDK update and the Scala version bump. For larger codebases, it is easier to treat the migration as a sequence of small, reviewable compiler-assisted changes than to diagnose every incompatibility after one big jump.

Compiler built-in rewrites

Pick a Scala compiler to run the rewrites on:
- Start with Scala 3.7.4 if the codebase often passes explicit arguments to standard-library methods that now need using. 3.7.4 is the last release before the standard library was compiled with Scala 3, and it can insert those using clauses before the 3.8 library boundary.
- Start with Scala 3.9.0 if the codebase uses a lot of with types. 3.9 improved the rewrite of with to &; the same flags on 3.7.4 could emit code that does not compile.

With that compiler, apply the -source:3.x-migration rewrites in order for each minor you are crossing, always with -rewrite: -source:3.4-migration, -source:3.5-migration, -source:3.6-migration, -source:3.7-migration, -source:3.8-migration, then -source:3.9-migration.

scalacOptions ++= Seq("-source:3.4-migration", "-rewrite")

Later flags do not replay earlier patches, so -source:3.6-migration does not apply the 3.4 rewrites. Run each flag in order.

Flag	What `-rewrite` changes
`-source:3.4-migration`	• `with` to `&` in types • `_` type wildcards to `?` • `xs: _` to `xs` • `var x = _` to `scala.compiletime.uninitialized` • drop `[this]` from `private[this]` / `protected[this]` • drop a trailing `_` used only for eta-expansion • backtick alphanumeric infix operators that are not declared `infix` • insert `using` on explicit arguments to context-bound parameters • insert `case` on refutable `for` generators
`-source:3.5-migration`	• no new rewrites
`-source:3.6-migration`	• named arguments on Java-defined annotations • `(x = e)` rewritten to `{x = e}` where it would now be a one-element named tuple instead of an assignment
`-source:3.7-migration`	• insert `using` at call sites of `implicit` parameters • drop empty `()` that existed only to pass implicits • rewrite infix named-argument lists such as `x op (a = 1, b = 2)` to dotted `x.op(...)`
`-source:3.8-migration`	• refutable pattern bindings such as `val hd :: tl = xs` gain `.runtimeChecked` • `: @unchecked` ascriptions are rewritten to `.runtimeChecked`
`-source:3.9-migration`	• backtick identifiers that contain `$`

Some changes have no automatic rewrite. Fix those by hand as the compiler reports them.
Review each generated diff as ordinary source, then bump to Scala 3.9.0, drop the temporary migration flags, and run the full test suite.

If a change is hard to apply, for example when using illegal match types after SIP-56, you can compile that code with -source:3.x so Scala 3.9 treats the sources as if they were compiled with that earlier version:

scalacOptions += "-source:3.3"

Use this only for a subproject that is otherwise hard to migrate: newer language features stay unavailable until you remove the flag. The older language source rules are respected on a best-effort basis, it should be used as a temporary solution.

Scala 2.13 consumers via TASTy Reader

Scala 3 projects can continue consuming Scala 2.13 artifacts. The reverse direction has a boundary: Scala 2.13’s -Ytasty-reader can consume Scala 3 artifacts up to Scala 3.7, but not Scala 3.8 or later.

If you publish Scala 3 libraries for users who still consume them from Scala 2.13, read State of the TASTy reader and Scala 2.13 ↔ Scala 3 compatibility before moving those artifacts to Scala 3.9.

Runtime reflection with `scala-reflect`

Scala 3.8 and later can still depend on Scala 2.13 libraries, but there can be issues if a dependency uses scala-reflect for runtime reflection. Runtime reflection in scala-reflect 2.13 depends on ScalaSignature attributes in class files. From Scala 3.8 the standard library is compiled with Scala 3 and no longer emits those attributes, so scala.reflect.runtime.universe can fail as soon as it initialises; see scala/scala3#25896 for details.

There is no planned compiler or standard-library fix, and it is not yet clear whether a workaround in scala-reflect itself is possible. An experimental reimplementation of part of scala-reflect has been tried, but that work is not something you can depend on.

What you can do today:

Stay on Scala 3.7.x if you need those 2.13 artifacts as they are.
Avoid code paths that initialise scala.reflect.runtime.universe.
Migrate the reflection to the Java reflection API.

What’s next?

Scala 3.3.9 is expected within the next month and will continue the maintenance of the previous LTS line. It will backport fixes introduced between Scala 3.8.4 and Scala 3.9.0 that are safe for the 3.3 compatibility guarantees. Scala 3.3 LTS remains actively maintained for one year after Scala 3.9.0, giving library maintainers time to plan and communicate their move to the new baseline. Scala 3.9 LTS itself is guaranteed to be maintained for at least three years, the same commitment as for Scala 3.3 LTS; see the Scala LTS and Scala Next model.

As I write this, Scala 3.10.0-RC1 is already available and will be announced on channels such as contributors.scala-lang.org. Scala 3.10 continues the Scala Next line and is expected to contain more breaking changes than 3.9, especially in the standard library.

A glimpse of what is coming:

The standard library continues to move onto Scala 3 constructs, especially by using inline and replacing implicit classes with extension methods.
Stronger constant folding during inlining fixes several inlining bugs, but also exposes macros that build ill-typed trees - ZIO and a few other macro-heavy libraries needed new releases to stay compatible with it. It was left out of 3.9.0 so the new LTS stays usable with libraries published today, and can still land in a 3.9.x patch if users ask for it.
Features entering preview: SIP-61 Unroll, SIP-75 relaxed lambda syntax, and SIP-68 referenceable package objects.
Experimental inline and specialized traits, bringing specialization to Scala 3.
Pattern matching on Java records.
Support for select using directives within the REPL, including dep, toolkit and jar, with more to come.

The full changelog for Scala 3.9.0 can be as always found in release note on GitHub.

Fixing a remote execution vulnerability in sbt

2026-08-10T00:00:00+02:00

This post covers work done under the Sovereign Tech Fund investment umbrella: sbt 2 Stable Release and Maintenance. The work is coordinated by the Scala Center.

TL;DR

Only builds that explicitly set serverConnectionType are affected. You can remove the setting from your build, or upgrade to sbt 1.12.15 / sbt 2.0.6 or later by putting the following in project/build.properties:

sbt.version=1.12.15

Note that installing a new sbt command does not affect the sbt version used by each individual build.

The vulnerability

As part of our ongoing work on the sbt 2 release, we’ve been reviewing bug reports and pull requests.

Recently we received a security report GHSA-m2pw-22cj-jq4v from Arpit Jain that an attacker is able to execute arbitrary code remotely via the sbt server when the serverConnectionType is set to ConnectionType.Tcp.

By default, sbt uses UNIX domain sockets on Linux and macOS, and named pipes on Windows, but this can be changed to TCP using the following setting:

Global / serverConnectionType := ConnectionType.Tcp

This will use a TCP port that can be calculated deterministically from the working directory, e.g. 5001, for the sbt server communication. An attacker can then craft a JSON-RPC message, masquerading as an sbt client.

In a normal sequence, using TCP would go through a token authentication so only the local user can use the sbt server; however, there were several endpoints that were not protected by the access control, which allowed improper escalation. This is a form of CWE-425: Direct Request. The vulnerability has existed since sbt 1.1.0 and affects both the sbt 1.x and sbt 2.x series.

The fix

The primary fix was to make sure all LSP-like endpoints are protected behind authorization when using TCP. The fix is available in sbt 1.12.15 and 2.0.6. The remediation was implemented by Eugene and Anatolii using GitHub’s private fork feature. The full advisory is available as GHSA-m2pw-22cj-jq4v.

We recommend removing the serverConnectionType setting from your build, or upgrading to a patched version sbt 1.12.15 / sbt 2.0.6 or later.

AI tooling

When Claude Mythos 5 was announced, it was widely reported that the LLM had reached the ability to discover new vulnerabilities in software. Subsequent availability of Claude Fable 5 and competing models have put the idea to the test. In the security report, the reporter has noted that he used AI assistance for the code audit and for drafting this report, and including detailed tracing of functions across multiple source files. When we prompted Claude Fable 5 to discover vulnerabilities, it downgraded itself to a previous model as a safeguard, but discovered the same remote execution bug nonetheless. We might actually be in the age of discovery-capable LLMs.

We’re thankful that the vulnerability was reported to the sbt team. If you find one please report through GitHub advisories.

Participation

The Scala Center has been entrusted with coordinating the commissioned Scala work for the Sovereign Tech Fund. The Scala Center is an independent, not-for-profit center sponsored by corporate members and individual backers like you to promote and facilitate Scala. If you would like to participate and/or see more of these types of efforts, please reach out to your manager to see if your company can donate engineering time or membership to the Scala Center.

See The Scala Center Fundraising Campaign for more details.

Coaxing quality output from generative AI

2026-07-06T00:00:00+02:00

This post covers work done under the Sovereign Tech Fund investment. The work is coordinated by the Scala Center. The work described in this post was done by Bill Venners and Chua Chee Seng of Artima.

One of the tasks funded under the STA project is to improve Scala’s API documentation. Such a task looks like a natural fit for generative AI, because the work is repetitive and the code to document is nearby in the source. But handing the work to an AI raises two challenges. The first is quality: an AI model will readily produce documentation, but it may be mediocre or wrong. The second challenge is managing human review time: someone will have to check all that output. This post is a report on how we approached these problems when using AI to improve API documention of Scala’s standard library: what we tried and how it worked out.

Quality writing requires iteration. You write a draft, review it (or have someone else review it), then improve it. You repeat this process until you’re happy with the quality. One way to achieve quality with generative AI, therefore, is to delegate the writing part to the AI model and review it yourself, but this doesn’t scale. An AI model can generate content at a much greater rate than you can review it. Because of this, we decided to use the “LLM as a judge” technique in an attempt to raise the quality of the output as high as possible prior to asking humans to review it.

Another way we tried to raise the quality of the AI output prior to human review is to use harnesses to orchestrate the AI work. First, we wrote a todo-writer application that reformatted doc comments for consistency and inserted text markers in the standard library source to precisely indicate where we wanted an AI to insert focused documentation. Then we created a script to drive the filling-in process. Finally, we attempted to keep the review tasks for humans to a reasonable size.

The rest of this post describes five techniques that formed our overall approach.

Technique 1: Push work onto deterministic code

The first pull request we submitted, which made the style of existing documentation more consistent, was done simply by asking an AI model to find and make the changes, and then reviewing the results. This prompting technique worked fine given the limited scope of those changes.

Next, we wrote and ran a Scala application to convert wikidoc to markdown, the recommended markup language for Scala 3, and ran it across the entire standard library. We hoped this would make the documentation in the source code nicer for humans to work with. We also felt it would provide a more consistent canvas on which into ask AI models to fill in missing documentation. This resulted in our second pull request. The application we used was todo-writer, run with the --migrate-markdown command line argument.

We next ran todo-writer across the standard library to insert TODO FILL IN markers wherever existing documentation was missing any @param, @tparam, or @return tags. Here’s an example:

/** Creates a new map obtained by updating this map with a given key/value pair.
 *  @tparam V1 TODO FILL IN
 *  @param key TODO FILL IN
 *  @param value TODO FILL IN
 *  @return TODO FILL IN
 */
def updated[V1 >: V](key: K, value: V1): CC[K, V1]

Each TODO FILL IN is one precise marker, which turned the AIs’ job from the open-ended “find and improve the documentation” into the mechanical “replace this text with the right content.” We could now focus the models on exactly those spots, with nothing about where to write or what needed writing left to their judgment.

The principle underneath this technique is to use determinism wherever you can. Lean on a deterministic program for every part of the job that does not genuinely require judgment, and strip out any nondeterminism that is not essential. Every piece of the job you hand to deterministic code is a piece the AI cannot get wrong.

Technique 2: Enforce a deterministic process

Another way we used determinism was by defining and enforcing a process through a shell script that called into the AI model, rather than asking an AI to run the entire task. This kind of orchestration is often called an “AI harness,” which both implies that an AI workhorse is being constrained as well as being put to productive use.

Our harness used two git branches. Once todo-writer had inserted the TODO FILL IN markers, we committed its output one file at a time, so that every file landed in its own commit, each carrying the same message: Todo-writer added TODOs for @param, @tparam, and @return tags. A small helper, commit-each-file.sh, did this slicing. The effect was to turn the whole task into an ordered queue of single-file commits on a source branch, with nothing else mixed in.

The loop itself, fill-todos-loop.sh, drained that queue onto a separate working branch. It listed the source commits not yet present on the working branch, oldest first, and handled them one at a time. For each commit it did five things. It cherry-picked the single-file change onto the working branch, so the file arrived with its TODO markers as one isolated commit. It ran a writer model (writer-prompt.txt) that replaced the TODOs in that one file with real documentation. It ran a reviewer model (reviewer-prompt.txt) that inspected the result and returned a structured JSON verdict. It ran the writer once more (refinement-prompt.txt) to act on that verdict. And finally it amended the cherry-picked commit, so that the file’s single commit now held finished documentation instead of placeholders.

The cherry-picking played a critical role: it was the loop’s iterator. Each source commit was exactly one unit of work, so cherry-picking popped the next file off the queue in order. The AI model never had to decide for itself which files needed attention or in what sequence, because that was settled when the queue was built. It also guaranteed that the output kept the same clean shape as the input, one commit per file, which later let us regroup the finished commits into review-sized pull requests. And because a file that had already been processed no longer appeared in the not-yet-applied range, the run was naturally restartable and could proceed in batches.

The benefit of this harness was to keep the AIs focused on small, isolated tasks inside a fixed process of create, review, and refine. That process takes time, but not my time: I ran it overnight while I slept, with deliberate pauses between files to spread out my token usage. (Note that if you need a task to finish faster in wall-clock terms, you can design processes that run in parallel.)

Technique 3: Give the AI a fresh, focused context

Our script gave the AI a fresh context for every step, not just for every file. For a single file the writer filled the TODOs in a fresh context, the reviewer judged the result in a second fresh context, and the refiner applied the review in a third, with nothing carried between them except the file itself and the reviewer’s written feedback. I kept each of those contexts as small as possible for two reasons: as context length increases, output quality can decline, and a larger context consumes more tokens on every turn. Although I was on a monthly subscription, I still did not want to burn more tokens than necessary.

That is also what gave the review step its independence. Because the reviewer started fresh, it never saw the reasoning the writer had used, so it came to the documentation cold even though it was the exact same AI model. Another approach is to use a different model for review, to reduce the chance that the reviewer shares the writer’s blind spots.

Technique 4: Separate the review from the decision

I used the same AI model for every step, and though it may have been a better choice to use a different model for review, the results showed that one model is sufficient, so long as each step runs in its own fresh context and is handed a single, clearly defined role. Across the loop that same model played three tightly focused roles, never more than one at a time:

The writer received a file full of TODO FILL IN markers and a single instruction: replace them with real documentation.
The reviewer examined the writer’s output and offered suggestions, emitting its findings as structured JSON. The reviewer’s only job was to critique and suggest; it changed nothing and decided nothing.
The refiner read the reviewer’s JSON alongside the file and made the call, deciding which suggestions to accept and which to ignore, and editing the documentation accordingly.

Separating these roles is the whole point. The reviewer never was given the opportunity to act on its own opinions; a separate session weighed those opinions against the file and decided what to do. And although a single model sat behind all three roles, each came to its task cold, with no memory of having written or judged the very thing in front of it. The model stayed the same; the role, and the context, were different every time.

Technique 5: Size the pull requests to the human

When it was time for human review, we packaged the changes into multiple PRs to make it more manageable. Although it was far better than one massive pull request containing all changes, the PRs we submitted still stretched what can be reasonably reviewed by humans.

The first pass shipped as twelve pull requests, split by area of the library: #25371, #25372, #25373, #25374, #25375, #25376, #25377, #25378, #25379, #25380, #25381, and #25996. Not all of them were comfortably human-sized; some were large enough that reviewing them in a single sitting was a slog. The humans slogged through anyway, and the work needed it: reviewers caught real problems in the generated documentation - inconsistencies across files, edits to text that should have been left untouched, broken Scaladoc markup, and some outright factual mistakes - and we fixed those within the same pull requests before they were merged.

A second round of pull requests followed, for a different reason. During the initial review, we found and fixed bugs in todo-writer itself: the earlier version had skipped some declarations that should have received tags, such as higher-kinded type parameters and multi-parameter-list constructors. Once those bugs were fixed, we re-ran the improved tool across the library, which surfaced the spots the original pass had missed. The newly added tags went into nine cleanup pull requests: #26119, #26120, #26121, #26122, #26123, #26124, #26125, #26126, and #26127.

What’s next

Everything described here filled in tags on declarations that already had a Scaladoc comment. The larger job still ahead is to document the declarations that have none at all, and there are many: 5,894 program entities in the standard library currently have no Scaladoc comment whatsoever. That is a harder problem than supplying a missing @param or @return, because there is no existing summary to build on, so reaching high quality will take more than the single create, review, and refine pass we relied on here.

For that next batch I want to elaborate the review side of the loop. Instead of a single reviewer, I plan to run several reviews of each change, including reviews by different AI models, so that more eyes, and more kinds of eyes, weigh in before any human does. The aim is the same as before: push the quality as high as the machines can take it, so that by the time a human takes over, the documentation is already good.

About the author

Bill Venners is president of Artima, Inc. He is the lead developer of the ScalaTest and Scalactic open source libraries and coauthor of Programming in Scala, Fifth Edition and Advanced Programming in Scala, Fifth Edition.

About the Scala Center

See The Scala Center Fundraising Campaign for more details.

sbt 2 is now available!

2026-06-29T00:00:00+02:00

This post covers work done under the Sovereign Tech Fund investment umbrella: sbt 2 Stable Release and Maintenance. The work is coordinated by the Scala Center.

After five years of development, sbt 2 is out. Since the experimental sudori part 1 blog post in 2021, more than 82 people have contributed to the project. We would like to thank community and corporate contributors, Scala Center, and Sovereign Tech Fund for their support.

What’s new in sbt 2?

sbt 2 is a new version of sbt. If you’re familiar with sbt 1.x, hopefully the jump is not too far, but we have pushed sbt to the modern standard. The headline features are:

sbt 2.x uses Scala 3.8.4 for build definitions and plugins (Both sbt 1.x and 2.x are capable of building Scala 2.x and 3.x), which requires minimum JDK 17
Uses sbtn (native-image client) for faster startup.
test changed to incremental test.
Local/remote cache system that is Bazel-compatible. compile and test are both rewritten to be cachable tasks.
Project matrix, which was available via plugin in sbt 1.x, is in-sourced in sbt 2.x.
Client-side run.
Client-side console.
New documentation.

For more details, please check out sbt 2.0 changes summary and the Scala Days 2025 talk sbt 2.0: go big from 2025.

How do I get started with sbt 2?

The sbt version used for your build is upgraded by putting the following in project/build.properties:

sbt.version=2.0.1

This mechanism allows that sbt 2.0.1 is used only for the builds that you want.

Download the official sbt runner from SDKMAN, or download from https://github.com/sbt/sbt/releases/tag/v2.0.1 to upgrade the sbt shell script, sbtn, and the launcher.

Repopulating the plugin ecosystem

Major plugins are already available on sbt 2.x.

Under the sbt 2 workstream, Anatolii from Scala Center has created the sbt2-compat plugin, which bridges the source-level differences between sbt 1.x and 2.x. This allows cross-building of a plugin, aiding the migration process. Also under the STA workstream, Rikito Taniguchi from VirtusLab has cross built Scala.JS plugin to sbt 2.x (scala-js#5314).

Plugin	Version	Published
Scala.JS	`1.22.0`	✅
Scala Native	`0.5.11`	✅
sbt-assembly	`2.3.1`	✅
Play	`3.1.0-M9`	⚠️

This means we can now cross build JVM / JS / Native using sbt 2.x!

Client-server by default

The sbt runner script is capable of running either sbt 1.x build or 2.x build. When the sbt runner detects an sbt 2.x build, it will now launch the native sbtn client. This will start the sbt server as a background process, and sbtn will send the command. This means that, if you wish, you can use your system shell:

$ sbt compile
$ sbt test

The client program is gradually getting richer. For example, it can launch Scala REPL when the console task is detected. This keeps sbt server available for other tasks.

Project matrix

sbt 2.x ships with project matrix, which lets you cross build multiple versions of Scala and multiple platforms (JVM, JS, and Native). With projectMatrix, you declare the platform rows you want in one place. Each row becomes a normal subproject. For example, this defines JVM, Scala.js, and Scala Native rows:

lazy val core = (projectMatrix in file("core"))
  .settings(
    name := "core",
  )
  .jvmPlatform(...)
  .nativePlatform(...)
  .jsPlatform(...)

For Scala.js and Scala Native, add the plugins:

// project/plugins.sbt
addSbtPlugin("org.scala-native" % "sbt-scala-native" % "0.5.11")

addSbtPlugin("org.scala-js" % "sbt-scalajs" % "1.22.0")

Using cross-published libraries

In sbt 1.x, Scala.js and Scala Native builds required %%% for dependencies, so that the platform-specific suffix is included in the artifact name. In sbt 2.x, cross-built dependencies can be written with %%, just like JVM libraries:

libraryDependencies += "org.typelevel" %% "cats-effect" % "3.5.4"

See Cross building and Cross building setup for more details.

Let us know what you think

Have you tried sbt 2? Let us know what you think in the discussion forum. If you find a bug, please let us know as well.

Participation

See The Scala Center Fundraising Campaign for more details.

sbt 2 was brought to you by many contributors, including those who contributed to sbt 1.x series, migrating plugins, but according to git shortlog -sn --no-merges 00eba85d98c854527125ae1655b5332c19b5afd8...733bcfb23997930915b563e7d27b1a1f6c0490da --not 1.11.x and git shortlog -sn --group=author --group=trailer:co-authored-by --no-merges 242bd18d30c418620024d089b587f6d263d34247...v2.0.0 --not 1.12.x:

545 Eugene Yokota (eed3si9n)
217 Kenji Yoshida (xuwei-k)
146 Adrien Piquerez
51  Jerry Tan (friendseeker)
37  MkDev11
34  bitloi
30  Scala Steward
21  calm329
16  Anatolii Kmetiuk
15  dependabot[bot]
14  Yasuhiro Tatsuno
13  E.G
11  Pandaman
10  João Ferreira
9   Anton Sviridov
9   Brian Hotopp
8   Aleksandra Zdrojowa
7   Dream
7   GlobalStar117
7   Matt Dziuban
5   Dairus
4   Martin Duhem
4   john0030710
3   Angel98518
3   Brice Jaglin
3   Li Haoyi
3   gayanMatch
2   Ali Rashid
2   Billy Autrey
2   BitToby
2   Damian Reeves
2   Daniil Sivak
2   Dmitrii Naumenko
2   Douglas Ma
2   Frank S. Thomas
2   Jame4u
2   Josh Soref
2   Kamil Podsiadło
2   Marco Zühlke
2   Matthew de Detrich
2   Matthias Kurz
2   Michał Pawlik
2   Miguel Vilá
2   NeedmeFordev
2   Pluto
2   Renzo
2   Rikito Taniguchi
2   SID
2   Satoshi Dev
2   byteforge
2   circlecrystalin
2   it-education-md
1   Albert Meltzer
1   Deborah Funmilola Olaboye
1   Eve
1   Francluob
1   Guillaume Massé
1   Hamza Remmal
1   Hugo van Rijswijk
1   Idan Ben-Zvi
1   Jakub Kozłowski
1   James Roper
1   Karl Yngve Lervåg
1   Lazz
1   Lukas Rytz
1   Nikita Vilunov
1   OlegYch
1   Pegasus
1   Rex Kerr
1   Roberto Tyley
1   Saber
1   SalesforcePeak
1   SlowBrainDude
1   Zainab Ali
1   bohdansolovie
1   chrisrock1124
1   corevibe555
1   dev-miro26
1   dive2tech
1   fireXtract
1   kijuky
1   nathanlao

Thanks to everyone who’s helped improve sbt and Zinc by using them, reporting bugs, improving our documentation, porting builds, porting plugins, and submitting and reviewing pull requests.

Scala 3.3.8 LTS is now available!

2026-06-10T00:00:00+02:00

Scala 3.3.8 LTS is now available!

This patch release backports most of the bugfixes and some of the improvements introduced in the Scala Next series to the Scala 3.8.4 release. All of the backported changes were proven to not break either binary or source compatibility, by testing over 1500 projects in the Scala 3 Open Community Build.

Notable changes

Support for JDK 26 #24430
Multiple coverage improvement to make it on par with Scala 2 support including // $COVERAGE-OFF$ and // $COVERAGE-ON$ markers
New @uncheckedOverride annotation for definitions that may override. #24545
Trap Ctrl-C in the REPL: if no command is running clear the prompt, if some command is running ask for confirmation before exiting. #24127
Numerous linting and presentation compiler improvements and fixes.
New -Yfuture-lazy-vals options that allows to compile with new lazy val implementation compatible with all JDK 9+ #637

For a full list of changes and contributor credits, please refer to the release notes.

Scala LTS Release Notice

The next planned LTS 3.3 release will include updates introduced until last Scala 3.9.x before 3.10. Scala 3.9.x will also be a new LTS release. We’ll continue to backport bug fixes and improvements from the Scala Next series to the 3.3.x series for the next year after the release 3.9.0.

Improving Scala's docs and website

2026-06-09T00:00:00+02:00

This post covers work done under the Sovereign Tech Fund investment. The work is coordinated by the Scala Center.

We have collected possible documentation tasks from three sources:

Tasks in the original proposal we made to the Sovereign Tech Agency
Tasks collected in internal discussions since then
Tasks from community suggestions on this Contributors forum thread

This blog post summarizes what we have collected, identifies tasks that we have chosen to tackle, and describes work that is already underway.

Project goals

We aim to identify documentation, both API documentation (Scaladoc) and the docs on the Scala website, that is:

Outdated, or
Incomplete or poor quality, or
Missing entirely

And we want to address those shortcomings, to aid both:

New users coming to Scala
Existing users of Scala

Project scope

A major focus will be on the Scaladoc for the standard library. We will update and expand it. Along the way, if we find that limitations of the Scala 3 Scaladoc tool are causing quality issues in the doc, improving the tool is in scope.

The project scope also includes the documentation on our website such as the Scala language specification, getting-started docs, language tour, features guides, Scala Toolkit documentation, and so forth.

Scala 3 is the primary focus, but we can also make especially important improvements on the Scala 2 side.

What’s not in scope?

Third-party tools, libraries, and publications are not in scope.

That said, it is sometimes appropriate for our website and docs to describe and link to third-party documentation and resources. Examples of such documentation that is in scope for improvement include: the Scala community page, the Scala IDEs page, the Scala Toolkit documentation (because the Toolkit includes third-party libraries), and the Scala books page.

What did we initially propose?

In the Center’s original proposal we identified the following areas or “work packages”.

Any work we do must fit in at least one of these areas, and we must do some work in all of the areas. Note that the “Website” area is especially broad and can cover a wide variety of documentation tasks.

Work Package F: Documentation

F.1: Scaladoc: Core classes including collections
F.2: Scaladoc: Other classes
F.3: Scaladoc: Scala 3-specific classes
F.4: Website
F.5: Scaladoc: Individual methods

F.1/F.2/F.3 are for class-level documentation, F.5 for the methods within those classes.

What work is ongoing?

Work on improving our API documentation (Scaladoc) is already well underway. A series of PRs has already been merged and others are in the pipeline. These PRs were created with the help of AI-based tooling developed by Bill Venners and Chua Chee Seng. The process of doing this work with AI assistance will be documented, and the results described, in a future blog post by Bill.

Thanks to work done by Oliver Bračevac (from the Scala 3 compiler team), the infrastructure is now in place for compiler checking of code samples in the standard library Scaladoc and Scala 3 language. Many of the already-merged PRs take advantage of this new checking capability.

The goals of the API doc work are:

Ensure all code samples in the documentation are checked by the compiler.
Ensure every class has at least basic class-level documentation.
Ensure every method has at least basic method-level documentation.
Make sure method-level documentation meets minimum standards such as including @param, @return, and @throws annotations.
Further improve and expand any especially important or especially low-quality documentation.
Strive for all documentation to include applied, practical examples.

What else is planned?

We have chosen tasks that seem highest priority while also being feasible this year with the funding we have and suitable for the people we have available. After considering the community’s input, we’ve chosen the following work items for this year in roughly descending order of importance:

Essential

Improve issue reporting for documentation problems.
Reduce backlog of unhandled PRs and issues on website repos.
Document what language features debuted or progressed in what Scala versions.
Document all compiler options.

Also important

Write a new guide on Scala/Java interoperability.
Write a new guide on the REPL and its features.
Revise language reference to center Scala 3 rather than centering 2-to-3 migration.
Update language tour for Scala 3.
Ensure language reference isn’t missing any features.
Be consistent about where features are documented.
Update language specification.

If possible

Add links from beginner pages to in-depth docs.
Add links from reference docs to language spec.
Adopt Martin’s “common Scala style” proposal in examples.
Improve appearance and functionality of Scaladoc pages.
Improve Scala 3 syntax highlighting on websites.

Of course we can’t promise this will all get done, but we intend to at least make progress on the above.

The brief descriptions are not completely self-explanatory. There is more information about all of these items in the following detailed forum post:

https://contributors.scala-lang.org/t/scala-documentation-web-sites-what-should-be-improved/7354/35

And here is an additional forum post in which we responded to the rest of the suggestions received and explain why they were not selected in this round:

https://contributors.scala-lang.org/t/scala-documentation-web-sites-what-should-be-improved/7354/34

This second group of ideas remains open for volunteers to tackle. It’s also possible we might be able to address them in some future round of funding.

Participation

Scala Center team members on the documentation project are: Seth Tisue (team lead), Bill Venners, Chua Chee Seng, Guillaume Martres. Others may get involved later.

We welcome community participation as well.

See The Scala Center Fundraising Campaign for more details.

Scala 3.8.4 is now available!

2026-06-05T00:00:00+02:00

Release highlights

Security audit fixes

Scala 3.8.4 includes improvements and fixes for issues discovered during the Scala codebase security audit carried out in collaboration with the Open Source Technology Improvement Fund and Quarkslab. Notable fixes in this release include:

Hardened TASTy parsing to prevent infinite loops on maliciously crafted files (#25676)
Fixed a stored XSS vulnerability in Scaladoc (#25681)
Improved error handling in scala.sys.process.Parser.tokenize (#25675)
Fixed TastyPrinter’s JAR-walking logic to include subdirectories (#25678)

`:help` syntax for all compiler settings (#26052)

You can now append :help to any compiler setting to see its documentation — not just a fixed subset as before. This works wherever you pass compiler options, making it easier to discover available flags without leaving your workflow.

With the Scala runner, add :help to a flag on the command line when running a script or project:

> scala test.scala -Xkind-projector:help
-Xkind-projector  Allow `*` as type lambda placeholder to be compatible with
                  kind projector. When invoked as -Xkind-projector:underscores
                  will repurpose `_` to be a type parameter placeholder, this
                  will disable usage of underscore as a wildcard.
                  Default disable
                  Choices: disable, , underscores

In the REPL, pass the same flag through :settings:

scala> :settings -Wunused:help
-Wunused  Enable or disable specific `unused` warnings
          Choices:
          - nowarn,
          - all,
          - imports :
                Warn if an import selector is not referenced.,
          - privates :
                Warn if a private member is unused,
          - locals :
                Warn if a local definition is unused,
          - explicits :
                Warn if an explicit parameter is unused,
          - implicits :
                Warn if an implicit parameter is unused,
          - params :
                Enable -Wunused:explicits,implicits,
          - patvars :
                Warn if a variable bound in a pattern is unused,
          - linted :
                Enable -Wunused:imports,privates,locals,implicits

Upgrade to Scala CLI 1.14.0

The bundled Scala CLI has been upgraded from 1.11.x through 1.12.5, 1.13.0, to 1.14.0. Notable additions across these versions include:

v1.12.5: experimental --cross support for run, package, and doc; global --offline config key; experimental local .m2 in publish local
v1.13.0: Scala.js 1.21.0 support; Ammonite REPL deprecated and scheduled for removal; java-test-runner for pure Java tests; GraalVM native-image packaging via packaging.graalvmJvmId and packaging.graalvmArgs
v1.14.0: support for .test.java files; a toggle to turn auto-IDE-setup off

See the Scala CLI release notes for full details.

For the complete list of changes and contributor credits, see the release notes on GitHub.

Scala Codebase Security Audit Complete

2026-06-01T00:00:00+02:00

This post covers work done under the Sovereign Tech Fund investment umbrella: Maintenance of the Standard Library/Core Library Modules and APIs. The work is coordinated by the Scala Center.

The Scala Center is proud to share the first results of the security audit of Scala carried out in collaboration with Open Source Technology Improvement Fund and the security researchers at Quarkslab. The audit was divided into two major parts: an assessment of the Scala 3 compiler and Scala standard library codebases, and a separate review of Scala’s supply-chain security.

This first publication focuses on the compiler and standard library audit. Since many reported security issues in Scala ecosystems involve the standard library, the audit aimed to strengthen the security and robustness of Scala’s core components through a combination of manual code review and automated tooling, including fuzzing and Java deserialization gadget finders.

Results

Read the full report here.

No critical or major security issues were identified during the audit. However, the review uncovered 5 medium severity issues, 1 low severity issue, and 2 informational findings, all of which have since been addressed by the Scala maintainers. All of these issues are fixed as of the date of this blog post, both for the 3.3 LTS branch and for the main 3.8 branch.

Importantly, these issues do not affect typical users compiling Scala code locally or through continuous integration pipelines. Most findings were only relevant in scenarios where the Scala compiler is exposed as a service and processes untrusted input, where they could potentially lead to denial-of-service-type behavior.

Fixes

All reported issues were present in 3.8-RC1 and fixed before the publication of this blog post, both in the Scala 3.3 LTS branch and in the main Scala 3.8 development branch.

One example was a medium severity issue in the compiler’s handling of TASTy files. The compiler did not validate that certain offsets were nonnegative, which could lead to an infinite loop when processing a maliciously crafted TASTy file containing unexpected negative offsets. The fix introduced additional validation not only for this specific case, but more generally for parsing variable-length TASTy integers, helping prevent similar classes of issues in the future.

Summary

Severity	Description	Perimeter	Fixes
Medium	`scala.sys.Process.ProcessBuilderImpl.AbstractFunction0` may be used as a deserialization gadget	Standard library	Issue 25679
Medium	Stored XSS vulnerability	Scaladoc (Scala 3.8-RC1)	Issue 25681
Medium	Unexpected return value in `scala.collection.SeqOps.indexOfSlice` on empty sequences	Standard library	Invalid, Scala behaves the same as other languages here.
Medium	Uncaught `ParseException` in `scala.sys.process.Parser.tokenize` on unmatched quotes	Standard library	Issue 25675
Medium	Infinite loop during section loading in `dotty.tools.dotc.core.tasty.TastyUnpickler`	Compiler	Issue 25676
Low	Potential command injection in GitHub Action CI/CD scripts	GitHub Action workflows	Issue 25677
Low	Scala JVM bytecode could lead to conflicts between generated and user-defined methods	Compiler	Acceptable, no evidence it leads to any security issue.
Info	Use of a non-cryptographically secure random number generator	Compiler	Issue 25660
Info	`TastyPrinter` silently skips `.tasty` files in subdirectories of a `.jar`	`scalac -print-tasty`	Issue 26082

How to report future security issues

Please let us know as soon as you discover a security issue as per https://scala-lang.org/security/

Thank you

We first began discussions with the team at Open Source Technology Improvement Fund in July 2024. Between defining the scope of the audit, securing funding, assembling the teams, and carrying out the work itself, nearly two years passed before reaching this milestone.

Projects like this are a reminder that open source work takes time, collaboration and coordination, patience and persistence, and countless contributions along the way.

And so, we extend our gratitude to every person and organization involved in making this effort possible, including the Sovereign Tech Agency, the Open Source Technology Improvement Fund, Quarkslab, and the many Scala teams and maintainers who contributed along the way. We also look forward to sharing the final part of the audit, focused on Scala’s supply-chain security.

Participation

See The Scala Center Fundraising Campaign for more details.

Scala Days 2026: Call for proposals open

2026-04-30T00:00:00+02:00

Scala Days 2026: Call for proposals open

Submit your talk https://cfp.scaladays.org/scala26/cfp and be part of Scala Days 2026!

The Call for Proposals is now open and will close on May 31, 2026, at 23:59 CEST.

The Program Committee is looking for talks, labs, and workshops that showcase how Scala is evolving and delivering value in today’s fast-changing technology landscape.

In particular, we’re excited to hear practical insights, real-world experience reports, and forward-looking ideas.

See the topics below for inspiration.

Kind reminder: Super Early Bird tickets are available only until the end of the day on April 30, 2026.

Formats

This year’s program includes three submission formats. Talks and Interactive labs are part of the main conference program, while Workshops take place after the conference and require a separate ticket.

Talks (30 minutes)

Classic conference talks for sharing ideas, lessons learned, technical deep-dives, and real-world experience.

We’re looking for talks that bring real value to the community: practical insights, innovative approaches, hard-earned lessons, or fresh perspectives on Scala and its ecosystem.

We will select up to 48 talks, organized across 3 parallel tracks as part of the main conference program.

Interactive Labs (2 hours)

Interactive labs are a new format at Scala Days 2026: small-group, highly interactive sessions built around live demos, guided exploration, and practical experimentation during the conference.

This format is ideal for showcasing tools, libraries, frameworks, and new ideas in action. The goal is for participants to explore, experiment, and leave with practical experience they can immediately apply.

Because sessions are limited to 2 hours total, proposals should be designed to get participants engaged quickly, with minimal setup time and a clear path into the core experience.

Interactive labs are also a great fit for open-source maintainers who want to introduce their projects, onboard new users, and grow their contributor community.

We will host up to 16 Interactive labs, organized into two dedicated conference time slots, across both days.

Each session is limited to 10 participants, with seats allocated on a first-come, first-served basis.

Workshops (2 days)

Workshops are in-depth training sessions held after the main conference, on October 14–15.

Unlike Talks and Interactive labs, Workshops require a separate ticket and provide dedicated time for deeper exploration of a topic through practical exercises, discussion, and guided learning.

They are designed to equip participants with substantial knowledge and practical experience over the course of two full days.

Topics

These topics are intended as guidance, not limits. If your proposal is relevant to the Scala ecosystem, we want to hear it.

Experience & Industry

Experience reports
Industrial adoption
Libraries and applications
Distributed systems
Scala-based contracts

Data & AI

Machine learning in Scala
Big data
Scala in AI/ML pipelines
Integrating Scala with LLM-based systems
Scala’s role in data-centric and AI-driven architectures
Scala safety features for agentic systems

Development

Web development
Scala.js showcases
Game development
Native applications
Workflow and programming methodologies
Cloud and deployment
DevOps
Security

Tooling

Compilers and virtual machines
IDEs
Testing frameworks
Build tools
LLM-assisted development

Foundations

Functional programming
Type systems
Concurrency and parallelism
Algorithms and performance

Community

Open source
Teaching and mentoring
Community building

Other Areas

Hardware
Networking

Strategic & Forward-Looking Topics

Scala’s place in modern software ecosystems
How companies are using Scala in AI-driven environments
Adapting Scala to new architectural paradigms (data platforms, cloud-native, AI-first systems)
Real-world lessons from integrating Scala with emerging technologies

Get inspired

Need inspiration? Explore talks from previous editions of Scala Days on the YouTube channel.

If you have questions or need help with your submission, contact us at info@scaladays.org.

Last mile towards sbt 2

2026-04-14T00:00:00+02:00

This post covers work done under the Sovereign Tech Fund investment umbrella: sbt 2 Stable Release and Maintenance. The work is coordinated by the Scala Center.

At conferences or on social media, the question we get most often is:

When is sbt 2 coming out?

We’ll discuss the plan in this post. But let’s go over the status first.

What’s new in sbt 2?

sbt 2 is a new major version of sbt. If you’re familiar with sbt 1.x, hopefully the jump is not too far, but we have pushed sbt to a more modern standard. The headline features are:

sbt 2.x uses Scala 3.x (rather than Scala 2.12) for build definitions and plugins (Both sbt 1.x and 2.x are capable of building Scala 2.x and 3.x)
Embraces a simpler build.sbt via common settings
test changed to an incremental test
Local and remote cache system that is Bazel-compatible
Uses sbtn (native-image client) for faster startup
Project matrix that can cross build subprojects in parallel

For more details, please check out the Scala Days 2025 talk sbt 2.0: go big that I gave in August 2025.

To share the progress thus far, we released the sbt 2.0 ideas post in 2023, with sbt 2.0.0-alpha7. After a few more years of development, we released a beta version sbt 2.0.0-RC2 that’s ready for testing, around Scala Days 2025. Since then, we have been releasing more beta versions with both bug fixes and community-contributed feature enhancements. Perhaps surprising to some, sbt 2.x already started the binary compatibility from the RC series. This gave us a head start on repopulating the plugin ecosystem.

Repopulating the plugin ecosystem

Thanks to the community effort, we already have 60+ plugins ported to sbt 2.x. This is amazing for a build tool that hasn’t been released yet. Special thanks to Kenji Yoshida for pull requests, preparing and porting many plugins to sbt 2.

Under the sbt 2 workstream, Anatolii from Scala Center has created the sbt2-compat plugin, which bridges the source-level differences between sbt 1.x and 2.x. This allows cross-building of a plugin, aiding the migration process. Also under the STA workstream, Rikito Taniguchi from VirtusLab has created a pull request to cross build Scala.JS plugin to sbt 2.x (scala-js#5314).

Plugin	Version	Published	Notes
Scala Native	`0.5.11`	✅
sbt-assembly	`2.3.1`	✅
Play	`3.1.0-M9`	⚠️	Pending scripted tests.
Scala.JS	n/a	n/a	Pending scala-js#5314

Independently, the Play and Scala Native projects have been working towards sbt 2.x support as well.

Tooling support and documentation

Both IntelliJ Scala Plugin and Metals have published sbt plugins to import sbt 2.x projects.

Documentation has been reorganized and partly rewritten as The book of sbt, which has also been translated to Japanese and Chinese.

Locking down to 2.0.x branch

We have now created the 2.0.x branch, so by default, all pull requests will target sbt 2.1. Only the critical bug fixes will be backported to the 2.0.x branch.

On March 26, we released sbt 2.0.0-RC10, kicking off the last mile process.
On April 7, we released sbt 2.0.0-RC11.
On April 13, we released sbt 2.0.0-RC12.

Next steps: Please try using the latest RC on your projects, and check out the newly updated documentation. If you find bugs or missing documentation, please let us know by creating an issue on GitHub.

We will likely release a few more release candidates, but if no critical bugs are found, we will graduate one of them to the final release. So when is sbt 2 coming out? Depending on the bugs we discover, we are hopeful that it can happen in a few weeks to a few months.

Participation

See The Scala Center Fundraising Campaign for more details.

Fixing a Command Injection Vulnerability in sbt

2026-03-31T00:00:00+02:00

This post covers work done under the Sovereign Tech Fund investment umbrella: sbt 2 Stable Release and Maintenance. The work is coordinated by the Scala Center.

As part of our ongoing work on the sbt 2 release, we’ve been reviewing and hardening core parts of the sbt codebase. During that work, we discovered a command injection vulnerability in how sbt resolves source dependencies on Windows. The issue has been assigned CVE-2026-32948, rated Moderate (CVSS 6.7), and is now fixed. If you use sbt on Windows, update to sbt 1.12.8 or sbt 2.0.0-RC10 or later to apply the fix.

The vulnerability

sbt has the source dependencies feature that lets you depend on a VCS repository in your build definition. For example, to depend on the develop branch of a project published to GitHub:

lazy val dep = RootProject(
  uri("https://github.com/sbt/io.git#develop")
)

When sbt resolves this, it clones the repository and checks out the branch specified in the URI fragment - the part after #. To do this, sbt runs a VCS client (git, hg, or svn) as an external process.

On Windows, sbt historically wrapped these VCS commands in cmd /c - routing them through the Windows command interpreter. cmd.exe treats characters like &, |, and ; as command separators. The URI fragment is user-controlled and was passed to VCS commands without any validation. This allows an attacker to break out of the intended git command and execute an arbitrary shell command on Windows.

For example, consider a dependency declared as:

lazy val vulnerable = RootProject(
  uri("https://github.com/sbt/io.git#develop%26%26calc.exe")
)

The %26%26 decodes to &&. When this reaches cmd /c git checkout develop&&calc.exe, the command interpreter executes two commands: first git checkout develop, then calc.exe, starting the Windows Calculator.

This is a classic OS command injection (CWE-78). The vulnerability has existed since sbt 0.9.5 and affects both the sbt 1.x line and sbt 2.0 release candidates on Windows.

Severity

The severity is moderate because exploitation requires an attacker to actively build a project containing a malicious dependency URI, then requires a user to proactively build that project on their local machine. As sbt is a build tool, building a project carries an inherent risk of arbitrary command execution. As with any untrusted software, before building a project, you should check the source code, including the build file definitions.

The threat model here is that a malicious attacker may try to inject commands disguised as a source dependency URL, and pass the code review because the behavior is unexpected.

The fix

The primary fix was to stop routing VCS commands through cmd /c. Git, Mercurial, and Subversion all ship as .exe binaries on Windows. When Java’s ProcessBuilder invokes an .exe directly, arguments are passed as separate strings to the operating system - shell metacharacters are not interpreted. By removing the cmd /c wrapper, the injection vector disappears.

As defense-in-depth, we also added input validation. URI fragments are now checked against an allowlist of characters - only alphanumeric characters, -, _, ., /, and + are allowed.

Both measures follow established guidance from OWASP, Oracle’s Secure Coding Guidelines, and the JEP 8263697 proposal for safer process launching.

The fix is available in sbt 1.12.8 and sbt 2.0.0-RC10. The full advisory is published as GHSA-x4ff-q6h8-v7gw.

Workflow of applying the fix

One interesting detail to mention is that GitHub provides a way to report a vulnerability, work on the fix and submit a PR privately to prevent the vulnerability from being publicly disclosed before the fix is ready. If you encounter a security vulnerability in a Scala project, you should do the same, reporting it to the maintainers via Security Advisory on GitHub.

Applying the fix

Update your project/build.properties to sbt 1.12.8 or later, or sbt 2.0.0-RC10 if you are using sbt 2. If your build uses source dependencies, verify that the URIs point to repositories you trust. In general, treat build definitions and VCS dependencies (including their build and source code) with the same review standards as application code. A build.sbt runs arbitrary Scala at build time and deserves the same scrutiny as any other code in your repository.

Participation

See The Scala Center Fundraising Campaign for more details.

Scala 3.8.3 is now available!

2026-03-31T00:00:00+02:00

Scala 3.8.3 is now available!

Release highlights

Local coverage exclusions with `// $COVERAGE-OFF$` blocks (#24486)

Coverage-instrumented builds can now disable coverage for a selected region of code, instead of excluding a whole file or class. This is useful for generated code, intentionally defensive branches, or support code that would otherwise distort coverage results.

//> using scala 3.8.3
//> using options --coverage-out coverage-data

class Parser:
  def parse(input: String): Int =
    input.toInt

  // $COVERAGE-OFF$
  def debugFallback(input: String): Int =
    if input == "zero" then 0
    else -1
  // $COVERAGE-ON$

@main def CoverageTest = {
  val parser = Parser()
  assert(parser.parse("42") == 42)
}

Only the code between the markers is skipped by coverage instrumentation. The rest of the file is still measured as usual.

Safe mode for capability-safe code (#25307)

Scala 3.8.3 introduces safe mode, a new experimental language subset that can be enabled with import language.experimental.safe or -language:experimental.safe. As described in the safe mode reference, this is not just “stricter capture checking”: it is a capability-safe subset intended for agent-generated or otherwise untrusted code.

The underlying model is also described in the research paper Tracking Capabilities for Safer Agents, which proposes using Scala 3 with capture checking as a programming-language-based safety harness for AI agents.

When safe mode is enabled, the compiler rejects unchecked casts and unchecked pattern matches, forbids escape hatches such as caps.unsafe, @unchecked, and runtime reflection, turns on capture checking with mutation tracking, and restricts access to global APIs unless they are known-safe or explicitly reviewed.

That last point is what makes the feature practical. Safe code is meant to call a restricted set of APIs directly, while effectful or implementation-dependent behavior can still be exposed through wrappers marked @assumeSafe. The implementation in #25307 makes that boundary explicit: @assumeSafe declarations are themselves written outside safe mode, and safe code calls them from within the restricted subset.

// app.scala

//> using scala 3.8.3
//> using file CheckedMailer.scala
//> using options -experimental

import language.experimental.safe

object PotentiallyUnsafeApp:
  val address = EmailAddress("team@scala-lang.org")
  CheckedMailer.send(address)  // ok
  println(address)             // error: rejected in safe mode
  address.asInstanceOf[String] // error: rejected in safe mode
  address match
    case EmailAddress(rawAddress) => ???  // error: rejected in safe mode

// CheckedMailer.scala

import scala.caps.assumeSafe

@assumeSafe
object CheckedMailer:
    def send(to: EmailAddress) =
        scala.Console.out.println(s"Sending message to $to")

opaque type EmailAddress <: String = String

object EmailAddress:
    @assumeSafe def apply(value: String): EmailAddress = value
    def unapply(value: EmailAddress): Option[String] = Some(value)

In the example above, the safe code in app.scala can call CheckedMailer.send, but the effectful operation is isolated behind an @assumeSafe boundary. By contrast, direct calls to println, unchecked asInstanceOf casts, or scala.caps.unsafe helpers are rejected in safe mode.

Scala 2 JVM optimizer ported to Scala 3 (#25165)

Scala 3 now includes the port of the Scala 2 JVM backend optimizer. The optimizer is opt-in: compiler flag -opt enables local bytecode optimizations, while -opt-inline:... controls which classes and packages may be inlined across call sites. This brings Scala 3 to feature parity with the Scala 2 optimizer and opens the door to performance gains for JVM applications.

Rather than enabling blanket inlining everywhere, it is usually better to start from explicit filters. The -opt-inline setting accepts a comma-separated list of patterns; ** matches all classes, a.** matches a package and its subpackages, <sources> matches classes compiled in the current run, and a leading ! excludes matches. The last matching pattern wins.

//> using scala 3.8.3
//> using options -opt
//> using options "-opt-inline:<sources>,my.app.**,!java.**,!org.example.**"
//> using options "-Wopt:at-inline-failed-summary,no-inline-missing-bytecode"

In this configuration, the optimizer may inline code from the current compilation (<sources>) and from my.app subpackages defined in external dependencies, but not from the JDK or the org.example packages. This is often a good starting point for applications. For libraries, the conservative choice is usually to inline only from <sources> or from packages you fully control.

The optimizer port also brings additional settings:

-Wopt:... enables optimizer warnings. Available choices are all or at-inline-failed-summary, at-inline-failed, any-inline-failed, no-inline-mixed, no-inline-missing-bytecode, and no-inline-missing-attribute
-Yopt-specific:... enables individual optimization passes such as copy-propagation, box-unbox, nullness-tracking, closure-invocations, or redundant-casts
-Yopt-inline-heuristics:default|everything|at-inline-annotated adjusts how aggressively the compiler chooses call sites for inlining
-Yopt-log-inline:<prefix> logs inliner activity for matching methods
-Yopt-trace:<prefix> traces optimizer progress for matching methods

The -Wopt options let you choose between a one-line summary for failed @inline calls, detailed per-callsite diagnostics, reporting for heuristic inlining failures, and warnings for cases where inlining could not even be decided because bytecode or Scala inline metadata was unavailable.

The -Y... optimizer flags are primarily intended for debugging and internal use. As with other -Y settings, they are not stable user-facing interfaces, and their exact behavior may change between releases.

As with the Scala 2 optimizer, inlining external code comes with a compatibility trade-off: if you compile against one version of a dependency and later run against a different one, any inlined bytecode will not pick up the dependency’s runtime bug fixes or behavior changes. In practice, that means aggressive cross-library inlining is best reserved for applications with tightly controlled runtime classpaths. Read more about binary compatibility of optimized code in the Scala 2 optimizer documentation

The long-term plan is to build on this work in Scala 3.9 by enabling optimizations for the Scala standard library and the compiler itself.

`-print-lines` is deprecated for removal, but remains accepted as a no-op (#25330)

Scala 3.8.3 restores the -print-lines flag for compatibility, but only as a deprecated no-op. This avoids breaking existing builds in a patch release while giving users time to remove the setting from their build definitions.

The flag no longer has any effect and is scheduled for removal in Scala 3.9.0.

For the complete list of changes and contributor credits, see the release notes on GitHub.

Announcing Scala Days 2026

2026-03-26T00:00:00+01:00

We are very happy to announce that the Scala Days 2026 conference will be taking place 12 - 13 October in Berlin, Germany, one of Europe’s most vibrant tech and open source hubs, known for its strong culture of collaboration and its growing role in advancing digital sovereignty through open technologies.

Grab your Super Early Bird ticket and join us in Berlin this autumn!

Co-located events

Workshops will follow on 14–15 October, with various community-driven, co-located events taking place around the conference, possibly including the preceding weekend.

Meet Plain Schwarz

For the Scala Days 2026 conference, the Scala Center partnered with Berlin-based company Plain Schwarz, internationally renowned for organising conferences like Berlin Buzzwords and FOSS Backstage. Join us in welcoming Paul and the Plain Schwarz team to the Scala Days community as we work together on a refreshed and dynamic 2026 edition that stays true to Scala Days’ core spirit: business-driven and community-infused.

Call to action

Get your tickets at Super Early Bird price until April 9th, 23:55 CEST.

Interested in sponsoring Scala Days 2026? Please inquire at info@scaladays.org.

To get early updates and special offers, please sign up for the mailing list.

Join the #scala-days channel on the Scala Discord to chat with fellow attendees.

Call for talk and workshop proposals opens late April 2026.

Porting the Scala 2 optimizer to Scala 3

2026-03-23T00:00:00+01:00

This post covers work done under the Sovereign Tech Fund investment umbrella: Maintenance of the Standard Library/Core Library Modules and APIs. The work is coordinated by the Scala Center.

We are porting the optimizer from the Scala 2 compiler to the Scala 3 compiler, improving the performance of Scala 3 applications without requiring developers to write more complex code. In early microbenchmarks of code written in a high-level functional style, we’re seeing 10-30% faster execution. But what exactly is this optimizer and why is it necessary?

This work is available as of version 3.8.3-RC3 of the Scala compiler.

Scala is a modern and concise language, meaning you can write code expressing what you want to do by composing primitives, rather than how to do it step-by-step. High-level code is easier to read and maintain, in addition to being shorter to write.

Scala’s expressiveness enables you to write what you mean:

def addOneMap(a: Array[Int]) = a.map(_ + 1)

However, from a CPU’s point of view, a high-level API like map is conceptually more complex than the equivalent low-level code. It’s a function call that is passed another function, leading to a “megamorphic” call site that is harder for the JVM to optimize, and the function argument might need a closure to be allocated on the heap if it captures local values. Compiled naïvely, the high-level call wouldn’t be as fast as this equivalent low-level loop:

def addOneLoop(a: Array[Int]) =
  val l = a.length
  val r = new Array[Int](l)
  var i = 0
  while i < l do
    r(i) = a(i) + 1
    i += 1
  r

You don’t want to write this loop, because its purpose is a lot less obvious and it is harder to maintain, but without compiler help, you might have to write it if that function is critical to your application’s performance. (Why would adding one to an array be critical to your app’s performance? Because you’re reading a pedagogical blog post and thus suspending disbelief!)

If you’ve ever written a map function yourself, you may recognize the loop above as being fairly close to how such a function is implemented, though the actual Scala implementation is a little more complex than you’d think because it needs to handle the mismatch between Scala’s generic array type and the JVM’s erased generics:

def map[B](a: Array[A], f: A => B)(implicit ct: ClassTag[B]): Array[B] =
  val len = a.length
  val r = new Array[B](len)
  var i = 0
  (a: Any @unchecked) match
    case a: Array[AnyRef]  => while (i < len) { r(i) = f(a(i).asInstanceOf[A]); i = i+1 }
    case a: Array[Int]     => while (i < len) { r(i) = f(a(i).asInstanceOf[A]); i = i+1 }
    /* ... 7 cases omitted for brevity ...  */
  r

This method’s complexity is necessary to handle every possible array you can throw at it. You could also implement it with less code by using reflection to handle any possible array with just one code path, but that would lead to slower execution. But in our addOne case, we only need the Array[Int] part. Type-checking the array isn’t needed, nor is casting a(i) inside the loop, and the whole ClassTag machinery could go away too.

Optimizing for the best of both worlds

How can we get the best of both worlds? By having an optimizer in the compiler that simplifies code and heuristically determines when it is beneficial to inline code to enable further simplifications. Scala 2 has had such an optimizer for years now, as documented here, and it’s finally time to port it to Scala 3! Let’s see why it works in a little more detail.

The optimizer takes care of turning our single-line addOneMap example into our fast addOneLoop version. The key technique to perform this is inlining: expanding the code of map into the function where it is called. This allows the optimizer to remove redundant branches and operations, such as removing the boxing of primitive types. The match is simplified to just one of its branches, the asInstanceOf and ClassTag disappear, and we end up with the fast version.

Inlining is powerful but can also have big drawbacks. For starters, your CPU keeps frequently-executed code in an “instruction cache” that is very fast to access. When common functions get bigger, fewer of them fit in that cache, so execution might become slower because fetching the code is slower even if the code itself has fewer function calls.

Furthermore, inlining is not always possible. A classic case is recursion: you cannot infinitely inline a function into itself. Some more tricky problems include the fact that you cannot inline a method that accesses a class’s private fields outside of that class. (At least not on the JVM, Scala.js does not have that problem.)

In this case, there is a heuristic modeling the fact that if a function call uses a function literal as argument, inlining it is probably worth it. There are other heuristics, such as one related to generic array operations in general, one that forces inlining of “forwarder” functions that merely call another function with minor changes to their arguments, and so on.

The JVM already has an optimizer as part of Just-In-Time compilation, but it’s designed to make Java code fast, and typical Java code does not look like typical Scala code, so there are some important optimization opportunities not covered by the JVM’s optimizer. Furthermore, the Scala compiler can optimize code at compile-time based on knowledge that is internal to the compiler and subject to change between versions, such as which Scala runtime functions are guaranteed to be pure or to always return non-null references.

Early results show that for individual methods such as the addOne example above, the optimizer successfully turns the high-level version into an exact equivalent of the low-level one, which translates to 10-30% gains in some microbenchmarks.

Limitations

Heuristics mostly lead to better performance, but performance is such a complex topic that no set of heuristics can guarantee improvements. It’s possible that enabling the optimizer on your specific codebase could regress some scenarios, which is why you should benchmark any performance-related change just as you would test any correctness-related change. You can override the heuristics with @inline and @noinline annotations, but these should be a last-resort solution that you re-evaluate frequently as the compiler and the JVM improve.

The other key limitation of the optimizer is that you can only use it if you know your dependencies at run-time are the same as the ones you had at compile time. For instance, if you compile against library org.example version 1.3.6, and tomorrow the maintainers of org.example release version 1.3.7 that fixes a bug in a small function, this bugfix only has an effect on the already-deployed version of your code if it actually calls that function, not if the optimizer inlined the buggy version into your code.

Thus, the optimizer targets application code as well as the standard library, and is an opt-in compiler setting. You should only use it for library code if you carefully select what inlining is allowed, as explained below. Typically this means only inlining code within your own library, or within dependencies you control.

Using the optimizer

Pass the flag -opt to the compiler to enable non-inlining optimizations, and -opt-inline:... arguments to enable inlining calls to specific packages.

For instance, -opt-inline:**,!java.**,!org.example.* tells the optimizer that inlining is allowed for all functions except those anywhere in the java package and those directly in the org.example package. More details are available with -opt-inline:help.

Future directions

Now that the optimizer is at feature parity with its Scala 2 incarnation, we hope to bring further optimizations to Scala 3. For instance, Range-based abstractions cannot always be fully eliminated today, but could with further work on the optimizer. If you’re interested, you can contribute either by participating as described below, or by contributing to the compiler itself!

Participation

See The Scala Center Fundraising Campaign for more details.

Hardening Scoverage Support in Scala 3

2026-03-11T00:00:00+01:00

This post covers work done under the Sovereign Tech Fund investment umbrella: Scoverage hardening. The work is coordinated by the Scala Center.

Summary

Code coverage is a key part of maintaining high-quality Scala projects. We’ve recently made progress on making Scoverage more robust for Scala 3, expanding the way we test it and discovering and fixing new issues.

Background

Measuring how much of your Scala code is exercised by tests sounds simple until you try to do it yourself. That’s where code coverage tools come in. Code coverage is not optional for many organizations. As one of the QA metrics, coverage helps ensure reliability of the solution which is especially important in regulated sectors. Scoverage is the standard coverage tool for Scala, built directly into the Scala 3 compiler as a dedicated phase.

A crucial requirement for Scoverage’s wide industry adoption is that Scoverage itself is reliable and well-tested. The tool is already tested via its own dedicated test suite - however, that is not enough. Most tricky bugs happen not in isolation but at intersections of language features. Therefore, Scoverage needs to be tested in interaction with all of the language features to be truly considered reliable. Furthermore, all future changes to the compiler should be tested in interaction with Scoverage to ensure the tool remains compatible with the compiler.

To guarantee such a level of reliability, we have recently started a systematic rework of the testing strategy for Scoverage. This article reports on the progress we’ve made in 2026 so far.

Enabling coverage on the compiler test suite

The first step was mapping out the current failures of Scoverage in interaction with other language features. The strategy for that was to enable Scoverage on the existing compiler test suite. This means, in addition to the usual CI run of the tests that we do for each new PR, now we run the same tests again, but with Scoverage enabled.

Under this mode, for each test we verify three things:

The compiler doesn’t crash
The coverage output file is produced
The coverage output file is valid and deserializable

As a result, we have discovered 97 failing tests when coverage instrumentation was switched on. Those tests are being addressed in the order of impact. They were disabled for the time being to allow the validation logic to be merged early, thus future-proofing Scoverage.

As for the rest of the tests, they are now running with coverage instrumentation for each PR, and passing them is a requirement for a PR to be merged to the compiler codebase. Furthermore, every newly added test to the compiler test suite is tested against Scoverage by default, thus preventing future PRs from unintentionally introducing Scoverage breakages.

Details of this work are in PR #25009.

Addressing breakages: erased values and the purity constraint

We have also taken the first steps to address discovered issues. A pattern that emerged is that failing tests were clustered around a few common root causes.

One of the root causes behind a significant cluster of failures was the interaction between coverage instrumentation and Scala 3’s capability system. Capabilities in Scala 3 are represented as erased values - values that exist at compile time but are eliminated at runtime. Because they are erased, they must be pure: they cannot have side effects, and the compiler enforces this constraint, failing compilation if that is not the case.

Coverage instrumentation works by injecting calls into the compiled code to record which expressions were executed. These calls introduce side effects. The erasure phase would then reject the result with an error.

The fix is conceptually simple: the coverage instrumentation phase now checks whether a value is erased and, if so, skips it. 23 tests that previously failed under coverage are now passing as a result of this fix, opening the door to using Scoverage together with capabilities.

Details in PR #25298.

Expanding the testing surface

The Scala 3 compiler’s test suite is extensive. The strategy has been to enable coverage testing incrementally: start with the core tests, exclude the currently failing ones so regressions are caught from day one, then gradually expand the testing surface and fix discovered issues.

The latest expansion of the testing surface was done after fixing the first cluster of issues. Coverage instrumentation is now also exercised on additional test suites such as rewrites, warn, explicit-nulls/pos, explicit-nulls/warn, and init test suites. As a part of this expansion, we have discovered 13 new breakages that are being addressed in the same manner.

Details in PR #25385.

Conclusion

To ensure the reliability of Scoverage in the industry, we are continuing to expand the testing surface of the tool and fix discovered issues. We will be sharing more updates as the work continues. If you are actively using Scoverage, your feedback is welcome! You can join the discussion on contributors.scala-lang.org or contribute Scoverage-related issues to the Scala 3 issue tracker.

Participation

See The Scala Center Fundraising Campaign for more details.

Migrating sbt plugins to sbt 2 with sbt2-compat plugin

2026-03-02T00:00:00+01:00

This post covers work done under the Sovereign Tech Fund investment umbrella: sbt 2 Stable Release and Maintenance. The work is coordinated by the Scala Center.

There’s an ongoing, community-driven effort to repopulate the sbt plugin ecosystem in preparation for the sbt 2 release. From sbt 1.x, plugin authors can cross publish against sbt 2.0 release candidates. To facilitate the plugin migration, we’ve created the sbt2-compat plugin.

The PluginCompat Pattern

sbt 2 is a major upgrade from sbt 1 and makes breaking changes on the API level. As a plugin maintainer, you want to preserve compatibility with sbt 1 when migrating - so you want to cross-publish your plugin for sbt 1 and sbt 2. Ideally, you want to have the same codebase that compiles for both sbt 1 and sbt 2. However, due to the breaking changes to the API, this is not always possible. You end up with a situation where the same concept is expressed in a different way in sbt 1 and sbt 2.

One such example is how files are represented in sbt 1 and sbt 2. In sbt 1, everything is a java.io.File, whereas in sbt 2 the types are more granular depending on the context. For example, HashedVirtualFileRef is used for classpath entries, VirtualFile - for task outputs and caching artifacts, VirtualFileRef - for path-like references. These types are defined in the xsbti package.

The current approach to handling these discrepancies is to have a single codebase that compiles for both sbt 1 and sbt 2, and use the PluginCompat pattern to provide a compatibility layer. For example, suppose you want to define a new task key that builds a JAR file and returns it.

In sbt 1, you would define it as:

lazy val assembly = taskKey[java.io.File]("Builds a deployable JAR file")

In sbt 2, you would define it as:

lazy val assembly = taskKey[xsbti.file.HashedVirtualFileRef]("Builds a deployable JAR file")

Since you want to use the same codebase for both sbt 1 and sbt 2, you would need to abstract over the file type and define it separately for each sbt version. So:

// src/main/scala-2.12/PluginCompat.scala
type FileRef = java.io.File

// src/main/scala-3/PluginCompat.scala
type FileRef = xsbti.file.HashedVirtualFileRef

You would then be able to define the task using this unified API:

lazy val assembly = taskKey[FileRef]("Builds a deployable JAR file")

This approach is a recurring pattern that you will encounter from plugin to plugin when attempting to cross-compile for sbt 1 and sbt 2. This is exactly the motivation behind the sbt2-compat plugin.

Cross-building for sbt 1 and sbt 2 using the sbt2-compat plugin

The above encoding of the differences in the file API between sbt 1 and sbt 2 is already abstracted and ready to be reused in the sbt2-compat plugin. This plugin follows a similar pattern to the sbt-compat plugin that handled cross-builds between sbt 0.x and 1.x. As a plugin maintainer, instead of manually defining the PluginCompat.scala shim as described above, you would instead add the sbt2-compat plugin to your build and use the PluginCompat pattern as before, relying on the unified implementation provided by sbt2-compat.

1. Add sbt2-compat to your plugin

Add the plugin in your plugin’s build.sbt (not project/plugins.sbt):

addSbtPlugin("com.github.sbt" % "sbt2-compat" % "<version>")

To cross-build for sbt 1 and sbt 2, see Cross building sbt plugins in the official migration guide.

ThisBuild / crossScalaVersions := Seq("3.8.1", "2.12.21")
ThisBuild / scalaVersion := crossScalaVersions.head

(pluginCrossBuild / sbtVersion) := {
  scalaBinaryVersion.value match {
    case "2.12" => "1.12.3"
    case _      => "2.0.0-RC9"
  }
}

For a concrete example, see sbt-assembly.

2. Use sbt2-compat to handle the API differences between sbt 1 and sbt 2

Let’s take a look at how sbt-assembly uses sbt2-compat to cross-build for sbt 1 and sbt 2. Here is how it is applied:

1. Task keys — Import FileRef and use it for task return types. Notice how the type comes from the sbt2-compat plugin and does not need to be defined manually. (AssemblyKeys.scala L6–10):

import sbtcompat.PluginCompat.FileRef

lazy val assembly                  = taskKey[FileRef]("Builds a deployable über JAR")
lazy val assemblyPackageScala      = taskKey[FileRef]("Produces the Scala artifact")
lazy val assemblyPackageDependency = taskKey[FileRef]("Produces the dependency artifact")

2. Shared logic — Import compat helpers and use them for classpath handling, file conversion, and module metadata (Assembly.scala L225–294):

import sbtcompat.PluginCompat.{FileRef, Out, toNioPath, toFile, toOutput, toNioPaths, toFiles, moduleIDStr, parseModuleIDStrAttribute}

// Classpath iteration
val (jars, dirs) = classpath.toVector
  .sortBy(x => toNioPath(x).toAbsolutePath().toString())
  .partition(x => ClasspathUtil.isArchive(toNioPath(x)))

// Convert classpath entry to File for JarFile
val jarFile = new JarFile(toFile(jar))

// ModuleID from metadata
val module = jar.metadata.get(moduleIDStr)
  .map(parseModuleIDStrAttribute)
  .map(m => ModuleCoordinate(m.organization, m.name, m.revision))
  .getOrElse(ModuleCoordinate("", jar.data.name.replaceAll(".jar", ""), ""))

// Return task output
toOutput(builtAssemblyJar)

3. Disabling task caching — Use Def.uncached so classpath tasks read fresh values on sbt 2 (AssemblyPlugin.scala L86–87):

import sbtcompat.PluginCompat._

assembly / fullClasspath := Def.uncached((fullClasspath or (Runtime / fullClasspath)).value),
assembly / externalDependencyClasspath := Def.uncached((externalDependencyClasspath or (Runtime / externalDependencyClasspath)).value),

Project status

sbt2-compat currently covers the core API surface needed for cross-building plugins that work with files, classpaths, and packaging:

sbt2-compat provides	Use for
`FileRef`, `Out`, `ArtifactPath`	Task key types, return types
`toNioPath`, `toNioPaths`, `toFile`, `toOutput`, `toFileRefsMapping`, `toAttributedFiles`	Classpath and file conversion
`moduleIDStr`, `artifactStr`, `parseModuleIDStrAttribute`, `parseArtifactStrAttribute`	Module metadata from classpath
`Def.uncached`	Opt out of sbt 2 task caching
`.name()` on `FileRef`	File name (via `FileRefOps` on sbt 1)
`toDirectCredentials`, `credentialForHost`	Credentials handling
`createScopedKey`, `setSetting`	ScopedKey / settings API
`attributedPutFile`, `attributedGetFile`, etc.	Attributed metadata (typed vs string keys)

Plugin-specific compat (e.g. custom disk caching, test API differences, Scala stdlib bridges like Streamable) stays in each plugin’s own PluginCompat.scala. sbt-assembly, for instance, still maintains local shims for its cache, test settings, and PackageOption types. The sbt2-compat README documents this design and lists known caveats.

Development model. sbt2-compat evolves iteratively by porting real-world plugins. Each port validates the existing API and may reveal missing compat methods. The idea is that as you port your plugins to sbt 2, you will discover gaps in the API that you can contribute back to sbt2-compat. For the exact development model, see the README.

Contributions are welcome! If you’re cross-building an sbt plugin for sbt 1 and sbt 2, the sbt 2 team would be happy to hear about your experiences! Share what worked, what didn’t, and what you wish sbt2-compat had. Pull requests with compat helpers that might help other plugins are welcome! You can share your experiences and participate in the discussion in the sbt 2 production-ready roadmap thread at the Scala Contributors forum.

Participation

See The Scala Center Fundraising Campaign for more details.

Scala 3.8.2 is now available!

2026-02-24T00:00:00+01:00

Scala 3.8.2 is now available!

Release highlights

Warning for `for` with many `val`s and overloaded `map` (#25090)

Scala 3.8’s betterFors (available since 3.7 under -preview) changes for-comprehension desugaring and removes an intermediate map used for consecutive val bindings.

The following code snippet behaves differently at runtime depending on Scala version used for compilation. In Scala 3.7.x and earlier it produces List((43,29), (43,30), (43,31)), but starting with 3.8 it results in Map(43 -> 31).

def f(x: Int): (Int, Int) = (1, x)

val result: Iterable[(Int, Int)] =
  for // warning: For comprehension with multiple val assignments may change result type
    (k, v) <- Map(1 -> 1, 2 -> 1, 3 -> 1)
    x      = k + v
    (a, b) = f(x)
    (y, z) <- Map(42 -> 27)
  yield (a + y, b + z)

Before (3.7): A synthetic tuple-producing map was inserted; that step could make Map select a generic map overload and become an Iterable (e.g. List)
In 3.8: That synthetic step is removed, so the conversion no longer happens and a different map/flatMap path can be selected.

The previous runtime behaviour can be achieved by explicitly converting first Map to Iterable type or by compilation with -source:3.7 settings.

The new warning highlights code where this migration risk exists.

Notable changes

Support :dep ... to add library dependencies in the Scala REPL #24131
Upgrade to Scala.js 1.20.2 #24898
Bump Scala CLI to v1.12.2 (was v1.11.0) #25217: New aliases for RC and nightly Scala versions. See the Scala CLI release notes for additional details: v1.12.0, v1.12.1 and v1.12.2

For the complete list of changes and contributor credits, see the release notes on GitHub.

State of the TASTy reader and Scala 2.13 ↔ Scala 3 compatibility

2026-02-20T00:00:00+01:00

With the release of Scala 3.8, Scala 2.13 and Scala 3 interoperability is no longer bidirectional.

Every Scala 3 version supports consuming Scala 2.13 artifacts. There are no reasons or plans to change that state.

The Scala 2.13 TASTy reader (-Ytasty-reader) remains useful for migrations and consuming Scala 3 artifacts, but it will never be able to consume Scala 3.8 and later artifacts. Scala 3.7 is the last minor version whose artifacts will remain consumable from Scala 2.

This post summarizes the current state, the compatibility boundaries, and the recommended publishing strategy for teams that still need Scala 2.13 to consume Scala 3 libraries.

What is the TASTy reader?

TASTy (Typed Abstract Syntax Trees) is the high-level interchange format used by Scala 3. Every Scala 3 compilation produces .tasty files alongside .class files. While .class files lose type information due to JVM type erasure (e.g. List[String] becomes List[Object]), TASTy files preserve the complete type information — generic types, union types, intersection types, and more.

The TASTy reader is a feature built into the Scala 2.13 compiler, enabled with the -Ytasty-reader flag. It allows a Scala 2.13 project to depend on libraries only published for Scala 3, by reading their .tasty files to reconstruct the precise type signatures that .class files alone cannot convey.

The TASTy reader was designed as a migration aid — not a permanent compatibility layer. It addressed a critical chicken-and-egg problem during the Scala 3 ecosystem bootstrap: library authors wanted to publish for Scala 3 but couldn’t abandon Scala 2.13 users, while application developers on Scala 2.13 couldn’t migrate until their dependencies were available. The TASTy reader broke this deadlock by enabling a forward-compatibility path, allowing Scala 2.13 projects to consume Scala 3-only libraries directly.

Technical limitations of the Scala 2 TASTy reader

Even though both Scala 2 and Scala 3 share most of the language features, some features of each cannot be used by the other. As an example, macros or existential types produced by Scala 2 cannot be represented or consumed by Scala 3.

The Scala 2 TASTy reader is able to consume the Scala 3 TASTy format, but is not able to correctly represent an increasing amount of language features in a semantically correct way. Some of the unsupported features include:

inline (including Scala 3 macros)
Union types
Match types
Context functions
Polymorphic function types
Trait parameters

The classpath compatibility guide documents which Scala 3 features are or are not representable for Scala 2 consumption: Scala 3 migration guide - classpath compatibility.

What changed in Scala 3.8

Scala 3.8 introduced a major ecosystem change by publishing scala-library artifacts compiled using Scala 3, instead of reusing the Scala 2.13 standard library. As a result, it introduced a major new dependency that needs to be covered by the TASTy reader when consuming from Scala 2.

What’s more, Scala 3 contained a mechanism to patch parts of the Standard Library to improve its performance, with its scala3-library_3 replacements. One such example is scala.Predef.assert, defined as a normal method in Scala 2 but replaced with a transparent inline variant in Scala 3. Inlines are one of the features that Scala 2 cannot support. Starting with Scala 3.8, this mechanism was removed and replaced with direct standard library modifications after ensuring both source and binary backward compatibility.

The standard library of Scala 3 is now compiled with enabled support for explicit-nulls and capture-checking. Unless explicitly enabled, this change is not visible to users. However, at the TASTy level, each of these introduces additional features that cannot be represented in a Scala 2 compatible way: union types and capture checking.

As a result, the old “Scala 2.13 ↔ Scala 3 sandwich” is no longer bidirectional at the classpath level.

Compile Classpath incompatibilities

Both Scala 2 and Scala 3 make strict assumptions about what’s available on the classpath and assume usage of scala-library artifacts matching exactly the version of scala-compiler. This is required for correct emission of references to members of the Scala Standard Library. Usage of an incompatible version can lead to severe problems resulting in compilation crashes. On the Scala 2 side, it can trigger bytecode optimizer failures, as described in the Scala 3.8.0 post-mortem. On the Scala 3 side, it can lead to references to members not yet introduced or already removed from the actively developed standard library. This requirement can easily be violated due to eviction rules of third-party dependencies and transitive dependencies on different versions of the Standard Library.

Eviction of the Standard Library can also affect build tools. As an example, sbt has always ensured the use of matching versions of scala-compiler, scala-library, and scala-reflect to ensure their compatibility. Their perspective was recently documented in the sbt 1.12.3 release notes “Smørrebrød - the end of Scala 2.13-3.x sandwich”. In that scenario, a Scala 2.13 project can pull in scala-library:3.8.x through for2_13Use3, while sbt still needs aligned Scala 2 compiler artifacts for the 2.13 side. That leads resolution to attempt org.scala-lang:scala-reflect:3.8.x (and scala-compiler:3.8.x), but these artifacts do not exist. The result is the well-known sbt update error: Error downloading org.scala-lang:scala-reflect:3.8.x.

Hard compatibility guarantee

Scala 3 consuming Scala 2.13 artifacts will remain supported for the foreseeable future.

That direction of compatibility is a hard requirement and remains part of the Scala 3 migration model. The no-longer-supported direction is specifically Scala 2.13 consuming Scala 3.8+ artifacts through the TASTy reader.

Stable TASTy reader compatibility (Scala 2.13.6+)

The table below starts at Scala 2.13.6 and covers stable, non-experimental TASTy support milestones.

Scala 2.13 release	Scala 3 minor version supported via `-Ytasty-reader`
2.13.6	3.0
2.13.7	3.1
2.13.9	3.2
2.13.11	3.3
2.13.13	3.4
2.13.15	3.5
2.13.16	3.6
2.13.17	3.7

Each Scala 2.13 release can consume artifacts from all Scala 3 versions up to and including the one listed in its row. For example, Scala 2.13.17 can consume artifacts published with Scala 3.0 through 3.7, but not forward-incompatible 3.8 or later. Intermediate Scala 2.13 releases between these milestones follow the most recent support level above.

Recommendations

For Scala 2.13 users

Keep TASTy-reader-based dependencies on versions published using Scala 3.7 or below.
Prefer dependencies published on Scala 3.3 LTS when available.
Plan migration of remaining Scala 2.13 modules to Scala 3 to remove reliance on the TASTy compatibility layer.

For Scala 3 library authors supporting Scala 2.13 users

We recommend cross-compilation of libraries for Scala 2.13 and Scala 3 so that each series can be natively consumed.

However, if that’s not possible we recommend for library authors:

Publish Scala 3 artifacts on Scala 3.3 LTS for that compatibility path.
Scala 3.3 LTS will remain actively supported until at least Q2 2027 (at least one year after Scala 3.9 LTS is released), making it the safest choice for the transition period.
Prefer publishing library using Scala 3.3 LTS - Scala 3.7 is not expected to receive further releases. Use Scala 3 Next series only if access to their features features is necessary.
Plan and communicate potential dropping of Scala 2.13 support with the users, before migrating to Scala 3.9 LTS.

Summary

The TASTy reader remains a migration bridge for Scala 2.13 with Scala 3.0 to 3.7 artifacts. That bridge does not extend to Scala 3.8+ artifacts.

At the same time, one direction is unchanged and guaranteed: Scala 3 consuming Scala 2.13 artifacts is always supported.

For mixed ecosystems that still need Scala 2.13 consumers, Scala 3.3 LTS is the recommended publishing baseline, with newer lines used only when post-3.3 features are required.

Recap of Advent of Code 2025

2026-02-12T00:00:00+01:00

Advent of Code, started by Eric Wastl, is an annual event providing daily programming puzzles between December 1st and December 12th.

Let’s see how the Scala community participated in Advent of Code 2025. We were pleased by the strong engagement on both the Scala Discord and on our solutions website.

Why we do this

At the Scala Center, we love writing code in Scala, and we hope you do too. One of our core priorities is to communicate excitement about Scala, which motivates us to participate in the Advent of Code and share experiences solving problems with Scala with the wider programming community.

Another key priority is to improve the onboarding experience for newcomers. Part of that experience comes from the first impressions someone has reading Scala code. We hope that through hosting articles on our solutions website, newcomers can see that programming in Scala is an elegant way to solve problems.

Engagement from the community

Discord channel

This year, there was lively conversation (with spoilers duly grayed out, of course!) in the #advent-of-code channel on the Scala Discord server. Thank you to everyone who shared their code and/or helped each other come up with the best solutions. We especially thank those who offered friendly help to Scala newcomers.

Community solutions

106 solutions were submitted to the website this year, including some from first-time contributors.

We give a special shout-out again this year to Paweł Cembaluk, who was the only participant to submit a solution for all 12 days.

Explainer articles

As usual, we reached out to the community to help write the daily articles that show well-coded, well-explained solutions. The community organized a posting schedule which led to a full set of 12 complete articles. Thank you to all the authors who contributed. Each article has the author’s name at the top. The articles are on our solutions website.

Summary

If you read this far, thank you again everyone for contributing to Scala and participating in Advent of Code, we hope you all had fun – and learned some things, too. See you in December 2026!

Scala Standard Library Process

2026-02-05T00:00:00+01:00

Contributing to Scala Standard Library

After a long freeze, the Scala 3 standard library is again open to contributions. The main place for contributing is now the Scala 3 repository.

Certain specific improvements might be eligible for backporting to Scala 2, but this will be the exception rather than the norm. To access most new functionality, you need to migrate to Scala 3.

The Process

The Scala 3 standard library is hosted in the scala/scala3 repository. Any changes that influence the standard library API should follow this process. If the changes are only internal, the process is the standard pull request one.

The person responsible for coordinating the process is the Scala Core Coordinator. Current Coordinator can be found on the Scala Core Team page.

The Scala Programming Language

Scala 3.9 LTS released!

Scala 3.9 LTS released!

What does LTS mean?

Looking back at Scala 3.3 LTS

What’s new in Scala 3.9?

SIP-71: Allow fully implicit conversions in Scala 3 with into - now stable

Documentation snippets can declare the errors they expect

Scala CLI updates

Scala.js 1.22

Inaccessible companion implicits will no longer be found in Scala 3.10

Other notable changes

Coming from Scala 3.3 LTS?

Scala 3.4

New stable features

Breaking changes

Other notable changes

Scala 3.5

Notable changes

Scala 3.6

New stable features

Breaking changes

Scala 3.7

New stable features

Breaking changes

Other notable changes

Scala 3.8

New stable features

Breaking changes

Other notable changes

Migration guide

Recommended upgrade order

Compiler built-in rewrites

Scala 2.13 consumers via TASTy Reader

Runtime reflection with scala-reflect

What’s next?

Fixing a remote execution vulnerability in sbt

TL;DR

The vulnerability

The fix

AI tooling

Participation

Coaxing quality output from generative AI

Technique 1: Push work onto deterministic code

Technique 2: Enforce a deterministic process

Technique 3: Give the AI a fresh, focused context

Technique 4: Separate the review from the decision

Technique 5: Size the pull requests to the human

What’s next

About the author

About the Scala Center

sbt 2 is now available!

What’s new in sbt 2?

How do I get started with sbt 2?

Repopulating the plugin ecosystem

Client-server by default

Project matrix

Using cross-published libraries

Let us know what you think

Participation

Scala 3.3.8 LTS is now available!

Notable changes

Scala LTS Release Notice

Improving Scala's docs and website

Project goals

Project scope

What’s not in scope?

What did we initially propose?

What work is ongoing?

What else is planned?

Participation

Scala 3.8.4 is now available!

Release highlights

Security audit fixes

:help syntax for all compiler settings (#26052)

Upgrade to Scala CLI 1.14.0

Scala Codebase Security Audit Complete

Results

Fixes

Summary

SIP-71: Allow fully implicit conversions in Scala 3 with `into` - now stable

Runtime reflection with `scala-reflect`

`:help` syntax for all compiler settings (#26052)

Local coverage exclusions with `// $COVERAGE-OFF$` blocks (#24486)

`-print-lines` is deprecated for removal, but remains accepted as a no-op (#25330)

Warning for `for` with many `val`s and overloaded `map` (#25090)