The Scala Programming Language

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

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.

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.

Postmortem of scala/scala3#24994

2026-01-29T00:00:00+01:00

Incident Date: January 13th, 2026
Nature of the incident: The Scala 3.8.0 artifacts contain invalid references to private fields

The TL;DR

The Scala 3.8.0 artifacts were released with invalid references to private fields in its standard library. The bug, while severe, only affects a very limited group of users. A hotfix was implemented and included in a subsequent 3.8.1 release. Both releases were then announced simultaneously (link to the announcement can be found here).

Recommendations

Upgrade directly to Scala 3.8.1, or 3.8.2 once it becomes available.
Scala 3.8.0 is discouraged from being used because of the issue described in this document.
The issue is not flagged by the compiler, it manifests in a NoSuchFieldError thrown at runtime. We believe the exposure is very limited, and it’s unlikely for users to be affected. Libraries compiled and published with Scala 3.8.0 are not corrupted and can be used safely.

Timeline

On Tuesday, 13th of January 2026 Scala 3.8.0 artifacts were published with a (at the time unknown) contract-breaking bug in its bytecode. The issue only got reported on Thursday, 15th of January, in the scalacenter/sbt-missinglink SBT plugin bug tracker under scalacenter/sbt-missinglink#54. This was re-raised in the Scala 3 compiler bug tracker a day later, on Friday, 16th of January, at scala/scala3#24994. The issue was identified as severe enough to be treated as an incident and postpone the release announcement until due investigation. A hotfix was proposed on Monday, 19th of January under scala/scala3#25008 and then merged on the next day, Tuesday, 20th of January.

The Scala Core Team decided not to cancel Scala 3.8.0. While the bug is severe, it would affect a very limited number of users. Moreover, libraries successfully compiled and published with 3.8.0 are not corrupted and can safely be used in the ecosystem. Scala 3.8.0 and 3.8.1 (containing the hotfix) were announced simultaneously on Thursday, 22th of January 2026 (link to the announcement can be found here), with advice for users to upgrade directly to 3.8.1.

What exactly happened?

If you are interested in the full technical details behind this incident, read on.

Scala 3.8 series, with 3.8.0 being its first release, introduces a standard library compiled with Scala 3, rather than depending on the Scala 2.13 standard library. This change is, however, under the restriction of being fully backward compatible with the old scala-library from Scala 2.13, as per standard compatibility guarantees of Scala 3. That proves difficult with classes, traits and methods annotated as @specialized, since Scala 3 does not currently support specialization.

The solution was to copy and adjust .class files for those cases from the library built by Scala 2.13. This allowed the team to preserve binary compatibility, which was then checked against the combined artifacts of Scala 2.13.16 and 3.7.4.

The actual issue lies in the fact that the standard library of Scala 2.13 is processed by its JVM Bytecode Optimizer. The tool can inline references to private fields. For example, in the case of private[this] val _empty, it does not have an accessor generated, but rather is accessed directly and then used by @inline def empty[T]. This then caused the library to have an inlined, direct reference to a private field, which has a different qualified name when compiled using Scala 3, and causes the failure.

Several similar cases were found during the investigation.

Examples

Empty Range.grouped

Note: Scala 3.8.0 throws an exception, where it should return a Boolean.

println(Range(0,0).grouped(1).hasNext

Scala 2.13.18:
```
false
```
Scala 3.7.4:
```
false
```

Scala 3.8.0:

Exception in thread "main" java.lang.NoSuchFieldError: Class scala.collection.Iterator$ does not have member field 'scala.collection.Iterator scala$collection$Iterator$$_empty'
  at scala.collection.immutable.Range.grouped(Range.scala:550)
  at snippet$_.<init>(snippet:1)
  at snippet_sc$.script$lzyINIT1(snippet:15)
  at snippet_sc$.script(snippet:15)
  at snippet_sc$.main(snippet:19)
  at snippet_sc.main(snippet)

Scala 3.8.1:
```
false
```

ArrayOps.ReverseIterator

Note: Scala 3.8.0 throws a different exception.

println(Array.empty[Int].reverseIterator.next)

Scala 2.13.18

Exception in thread "main" java.util.NoSuchElementException: next on empty iterator
  at scala.collection.Iterator$$anon$19.next(Iterator.scala:980)
  at scala.collection.Iterator$$anon$19.next(Iterator.scala:978)
  at scala.collection.ArrayOps$ReverseIterator$mcI$sp.next$mcI$sp(ArrayOps.scala:151)
  at scala.collection.ArrayOps$ReverseIterator$mcI$sp.next(ArrayOps.scala:150)
  at scala.collection.ArrayOps$ReverseIterator$mcI$sp.next(ArrayOps.scala:147)
  at snippet$.delayedEndpoint$snippet$1(snippet:1)
  at snippet$delayedInit$body.apply(snippet:65534)
  at scala.Function0.apply$mcV$sp(Function0.scala:42)
  at scala.Function0.apply$mcV$sp$(Function0.scala:42)
  at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:17)
  at scala.App.$anonfun$main$1(App.scala:98)
  at scala.App.$anonfun$main$1$adapted(App.scala:98)
  at scala.collection.IterableOnceOps.foreach(IterableOnce.scala:630)
  at scala.collection.IterableOnceOps.foreach$(IterableOnce.scala:628)
  at scala.collection.AbstractIterable.foreach(Iterable.scala:936)
  at scala.App.main(App.scala:98)
  at scala.App.main$(App.scala:96)
  at snippet$.main(snippet:65534)
  at snippet.main(snippet)

Scala 3.7.4

Exception in thread "main" java.util.NoSuchElementException: next on empty iterator
  at scala.collection.Iterator$$anon$19.next(Iterator.scala:973)
  at scala.collection.Iterator$$anon$19.next(Iterator.scala:971)
  at scala.collection.ArrayOps$ReverseIterator$mcI$sp.next$mcI$sp(ArrayOps.scala:151)
  at scala.collection.ArrayOps$ReverseIterator$mcI$sp.next(ArrayOps.scala:150)
  at scala.collection.ArrayOps$ReverseIterator$mcI$sp.next(ArrayOps.scala:147)
  at snippet$_.<init>(snippet:1)
  at snippet_sc$.script$lzyINIT1(snippet:15)
  at snippet_sc$.script(snippet:15)
  at snippet_sc$.main(snippet:19)
  at snippet_sc.main(snippet)

Scala 3.8.0

Exception in thread "main" java.lang.NoSuchFieldError: Class scala.collection.Iterator$ does not have member field 'scala.collection.Iterator scala$collection$Iterator$$_empty'
  at scala.collection.ArrayOps$ReverseIterator.next(ArrayOps.scala:151)
  at snippet$_.<init>(snippet:1)
  at snippet_sc$.script$lzyINIT1(snippet:15)
  at snippet_sc$.script(snippet:15)
  at snippet_sc$.main(snippet:19)
  at snippet_sc.main(snippet)

Scala 3.8.1

Exception in thread "main" java.util.NoSuchElementException: next on empty iterator
  at scala.collection.Iterator$$anon$19.next(Iterator.scala:991)
  at scala.collection.Iterator$$anon$19.next(Iterator.scala:991)
  at scala.collection.ArrayOps$ReverseIterator$mcI$sp.next$mcI$sp(ArrayOps.scala:151)
  at scala.collection.ArrayOps$ReverseIterator$mcI$sp.next(ArrayOps.scala:150)
  at scala.collection.ArrayOps$ReverseIterator$mcI$sp.next(ArrayOps.scala:147)
  at snippet$_.<init>(snippet:1)
  at snippet_sc$.script$lzyINIT1(snippet:15)
  at snippet_sc$.script(snippet:15)
  at snippet_sc$.main(snippet:19)
  at snippet_sc.main(snippet)

How was this fixed?

The solution was still to copy .class files for sources with the @specialized annotation from the library built by Scala 2.13. The difference in the approach is that this time, they were not processed with the JVM Bytecode Optimizer. Additionally, the Scala 2 library class files being used are now built in the Scala 3 compiler repository to ensure full control over how these artifacts are produced. This proved to solve the problem, as can be tested with Scala 3.8.1.

Why did it happen?

The issue was introduced due to a number of factors:

Copying of .class files the way it happened was necessary due to specialization (via the @specialized annotation or otherwise) never being implemented in Scala 3. While it was discussed in the past, it was decided the old approach was in need of a redesign and the necessary work was large in scope. As a result, it was delayed until an unspecified future.
While porting the standard library, its JUnit tests were not ported at the same time. We have since shown that the JUnit tests would not have caught this particular incident. Nevertheless, it was a risky bet, and we have now successfully run all the JUnit tests on the new library. (It is also worth pointing out that JUnit tests constitute a very small part of the unit tests applicable to the library.)
Despite an exceptionally long RC period, the issue was not discovered earlier. 3.8.0-RC1 was released as early as the 14th of November 2025. It took almost 2 months to discover the problem in user code. This is perhaps a reasonable argument for the problem being rather niche.
- For further context, the RC period is around 1 month, by default.
The difference introduced to the .class files of the old Scala 2.13 standard library by the JVM Bytecode Optimizer in comparison to the unprocessed files is, in the end, a nuance, a detail easy to miss in the grand scope of things. While in retrospect it is clear what should have been done, human error seems to be the biggest factor.

How do we stop it from repeating?

All things considered, this incident is a unique occurrence. That being said, the maintenance team spent the time on due investigation. Every step of the way has been re-thought and re-checked. Dedicated tests were implemented to catch similar incompatibilities in the future, so that no adjacent problem could happen unnoticed as the standard library is developed.

scalacenter/sbt-missinglink, the SBT plugin for which a bug report initially caught the issue, has proved valuable to include in the compiler testing pipeline.

The topic of implementing specialization in Scala 3 (even in a limited capacity) or working around the limitations of lacking thereof will be revisited in the future.

The Sovereign Tech Fund invests in Scala

2026-01-27T00:00:00+01:00

We’re truly excited to share that Scala has received an investment from the Sovereign Tech Fund to strengthen Scala’s long-term security, maintenance, and developer experience.

The work is coordinated by the Scala Center and runs for two years, with a total investment of €377,300.

The Sovereign Tech Fund is a program of the Sovereign Tech Agency that globally invests in open software components that build our core digital infrastructure.

The Sovereign Tech Agency and the Sovereign Tech Fund

The Sovereign Tech Agency is the first publicly funded organization in Europe that supports the development, improvement, and maintenance of open digital infrastructures. It is financed by the German Federal Ministry for Digital Transformation and Government Modernisation and is a subsidiary of SPRIND, the Federal Agency for Disruptive Innovation.

The Sovereign Tech Agency’s mission is to strengthen the open source ecosystem sustainably, focusing on resilience, technological diversity, and the people behind the code as foundations for a future-ready economy and modern society.

The Sovereign Tech Fund identifies and invests in open source software components that enable the creation of software, and supports key technologies with broad societal importance. Since October 2022, the Sovereign Tech Fund has invested a total of around €34 million in 95 critical technology projects.

Scala is critical digital infrastructure

Scala is widely used to build and operate essential systems across multiple industries. These systems include data pipelines and distributed applications, and some are in highly regulated environments like finance and public services. In these contexts, reliability is paramount. The safety, sustainability, and evolution of the Scala language and its tooling directly impact systems that people and institutions rely on every day.

This is why, in 2016, the Scala Center was founded with a clear mission: to make the Scala open-source ecosystem stronger, more resilient, and sustainable over the long term. Thanks to the continued support of Scala Center industry partners (through the Advisory Board program), EPFL, and the worldwide Scala contributor community, the ecosystem continues to grow stronger every day.

And today, with the Sovereign Tech Fund’s investment in Scala, this commitment is reinforced at a public-infrastructure level. We are very thankful that the Fund’s support recognizes Scala as critical digital infrastructure and enables sustained, focused work on the language’s core foundations over the coming years.

A closer look: what this investment will deliver

1) Security Audit

A dedicated security audit by Open Source Technology Improvement Fund (OSTIF) will uncover vulnerabilities and strengthen confidence in Scala’s core components. This supports not only Scala users, but also the broader environments where Scala runs, for example as a component of complex software supply chains. We are super thankful to the OSTIF team and support!

2) Improvement of scoverage

scoverage is a key tool in the Scala ecosystem for measuring code coverage. Improving it increases the reliability of Scala codebases and helps teams detect gaps in testing earlier, especially as systems evolve.

3) Maintenance of the Standard Library / Core Library Modules and APIs

Long-term maintenance of core libraries and APIs is critical for stability. This includes keeping foundational modules healthy, reducing technical debt, and ensuring compatibility across versions.

4) Modernization and extension of the Standard Library / Core Library Modules and API Documentation

As Scala continues to evolve, modernizing and extending core modules ensures the language remains productive and relevant, while also supporting gradual adoption and stable upgrade paths. The work also brings improvements to API documentation and Scala websites, to improve understanding.

5) Build tool major update: sbt 2.0

Build tools are the backbone of developer productivity. The major update to sbt 2.0 will make Scala projects easier to build, maintain, and understand. This will be impactful for new users and contributors, as well as for established projects. Among other improvements, sbt 2 adopts Scala 3 (in place of 2.12) as the language for build definitions.

The Scala Center’s role

The Scala Center has been entrusted with coordinating the commissioned work, check out the team working on the projects.

We are very thankful that this support recognizes Scala’s importance in the broader digital landscape, and for investing in foundational work that strengthens the reliability of the systems and services built on Scala across the public sector and industries.

Stay informed and get involved

We’ll share updates as work progresses, including milestones, delivered improvements, and opportunities to engage with the effort.

Scala is critical digital infrastructure, so keeping it healthy is a shared responsibility. If you’re using Scala in production, maintaining libraries, or contributing to tooling and documentation, your feedback and involvement help keep Scala strong.

In addition to occasional blog posts such as this one, we’ll also post more detailed updates, progress reports, and calls for feedback on our Discourse-based contributors forum at contributors.scala-lang.org. Please follow the relevant threads to stay informed.

Forum threads

Scala 3.8 released!

2026-01-22T00:00:00+01:00

We’re pleased to announce the release of Scala 3.8 — a significant release that modernizes the Scala ecosystem and paves the way for Scala 3.9 LTS. This release introduces a standard library compiled by Scala 3 itself, stabilizes highly-anticipated features like Better Fors (SIP-62) and runtimeChecked (SIP-57), and introduces experimental features including flexible varargs and strict equality pattern matching.

Known regressions

Notable regression in Scala 3.8.0 only:

A runtime regression was detected after publishing Scala 3.8.0 artifacts. Please use Scala 3.8.1 instead.

The issue could lead to JVM linkage errors at runtime. It may have affected Scala 3 users who execute Scala 2.13 libraries, as well as certain uses of specialized members in the Scala standard library. Any library published with Scala 3.8.0 is expected to remain binary compatible. Artifacts built with Scala 3.8.0 are safe to use and should stay binary compatible with subsequent Scala 3 releases.

A more detailed postmortem will follow shortly after the Scala 3.8 release announcement.

Notable regressions in Scala 3.8.1 and 3.8.0:

The following regressions still present in 3.8.1 will be addressed in a forthcoming 3.8.2 hotfix release:

Some for comprehensions have incorrect behavior at runtime (bug 24673)

Certain code involving calls to certain parts of the Java standard library fail to compile (bug 25133)

Cautious users may wish to wait for 3.8.2.

What’s new in Scala 3.8?

JDK 17 is now required

Important: This release requires JDK 17 or later for compilation and execution. If your project runs on an older JDK, you must upgrade before migrating to Scala 3.8.

The plans for this change were announced in early 2025 by the Scala team and are required to support future JDK 26+, which restricts access to sun.misc.Unsafe functionalities used by our existing lazy-vals implementation. For most end users this might be just a small adjustment, but this change needs to be considered by the library authors and communicated to their users. If your project still runs on an older JDK, you must first upgrade to at least 17 before upgrading to Scala 3.8. Upgrading earlier will allow you to benefit from new language features and improved performance on the modern JVM.

The LTS (long‑term support) version Scala 3.3 will continue to produce JDK 8 compatible bytecode, but all future Scala releases (including the 3.9 LTS) will require JDK 17 or higher. For library authors who need to keep compatibility with at least some older JVM versions, we recommend using upcoming Scala 3.3.8 LTS when it’s released in the next months. That version will provide a -Yfuture-lazy-vals flag which activates new implementation of lazy vals, which still requires upgrading to at least JDK 9.

Standard Library changes

Compiled with Scala 3

The Scala standard library has historically been compiled using Scala 2.13 and used by Scala 3 as-is, thanks to binary compatibility. In Scala 3.8 the library is now compiled with Scala 3. The change itself has been verified to be binary compatible and should not cause problems when migrating to Scala 3.8.

Source Incompatibility: Context bounds in standard library classes such as scala.reflect.ClassTag used in Array.empty[T] method, are now desugared to given instead of implicit. This change requires using modifiers when supplying explicit parameters.

object Array:
  def empty[T: ClassTag]: Array[T]

val fails = Array.empty(reflect.ClassTag.Int) // error: No ClassTag available for Any
val works = Array.empty(using reflect.ClassTag.Int)
val recommended = Array.empty[Int]

Most such errors can be automatically fixed by the compiler when using Scala 3.7.4 with -source:3.7-migration -rewrite options, before upgrading to Scala 3.8.

Looking ahead to Scala’s future, compiling the standard library with Scala 3 itself paves the way for Scala 3 to eventually have its own standard library, free from the constraints of compatibility with Scala 2. However, this process will not actually begin until Scala 3.10.

REPL becomes a separate artifact

Breaking Change: Starting with Scala 3.8, the REPL is distributed as a separate artifact. Projects and tools that depend on the REPL must add an explicit dependency on scala3-repl.

This makes it easier to embed the REPL in tools, reduces the size of the core compiler distribution, and allows for easier integration with external dependencies.

The previous REPL printer was not dealing well with long expressions or literals, making the output difficult to read.

Starting with Scala 3.8 REPL rendering is now powered by com-lihaoyi/fansi and com-lihaoyi/pprint. This change allows us to provide better user experience, and present results in cleaner, formatted output.

Stabilised language features

SIP-62: For comprehension improvements

The Better Fors desugaring previewed in Scala 3.7 is now stabilised and enabled by default. The improved desugaring removes some of the surprising behaviours of traditional for‑comprehensions and produces more efficient code. Two key improvements are:

Aliases before generators - You can introduce alias definitions at the start of a for‑comprehension:

for
  sizes = List(1, 2, 3)
  size <- sizes
yield size * 2

Avoiding unnecessary map calls - When the last generator yields a value of the same type as its input, the for‑comprehension now emits direct code without an intermediate map call. This simplifies the generated bytecode and avoids constructing unnecessary tuples.

SIP-57: Replace non-sensical `@unchecked` annotations

runtimeChecked is now a standard feature. It enables you to opt-out of certain static checks and defer them to runtime without resorting to the older, syntactically awkward : @unchecked type ascription.

Consider the following example that tries to load an optional config value and match it against known values.

def portFromConfig(name: String): Option[Int] = ???

val Some(httpPort) = portFromConfig("http") // warning: right hand side expression is Option, not Some

portFromConfig("https") match 
    case Some(port) => println(s"HTTPS port: $port")  
    // warning: match may not be exhaustive.

The compiler detects and warns that in some cases your program throw an exception at runtime. The previous : @unchecked annotation could have been used to suppress these warnings, but its syntax made it difficult to apply. The new runtimeChecked clearly marks that given operation might fail, similar to .head or .get. What’s more, it’s perfect for use in chained calls!

def portFromConfig(name: String): Option[Int] = ???

val Some(httpPort) = portFromConfig("http").runtimeChecked 

val otherPort = portFromConfig("https")
    .map(_ + 1)
    .runtimeChecked
    .match 
        case Some(port) => port

runtimeChecked only suppresses checks that can be performed at runtime. If you write an obviously wrong pattern (for instance, matching an Int against a String) the compiler still emits an error.

New preview features

Preview features are only enabled if the -preview flag is used. Features that have reached the preview stage are always eventually stabilized, but may change incompatibly before that time.

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

Scala 3 normally requires import scala.language.implicitConversions anywhere you use scala.Conversion instances implicitly. The new into keyword provides two opt-in ways to allow implicit conversions without that import:

into[T] as a type constructor: marks specific parameter types as “conversion allowed”, giving fine-grained control (only where you wrap with into[...])
into as a soft modifier: declares a trait, class, or opaque type alias as an into target (e.g., into trait Modifier), so conversions to that type are allowed everywhere without rewriting lots of signatures

//> using options -preview

import scala.Conversion
import scala.Conversion.into

// Library code: allow conversions into IterableOnce[A] for this parameter only
def concat[A](xs: List[A], ys: into[IterableOnce[A]]): List[A] =
    xs ++ ys // inside the body, `ys` is treated as IterableOnce[A]

// User code: no `import scala.language.implicitConversions`
given Conversion[Array[Int], IterableOnce[Int]] = _.iterator

val xs = List(1, 2)
val ys = Array(3, 4)

val out = concat(xs, ys)   // `ys` is implicitly converted because expected type is `into[IterableOnce[Int]]`

into is currently a preview feature and is planned to be stabilised in the next minor version. It requires compilation with -preview compiler flag and can be activated using import scala.language.experimental.into. If you previously used experimental annotation-based preview implementation be aware of source incompatibilites when upgrading to Scala 3.8.

More information about into modifiers can be found in the dedicated reference.

Experimental features changes

Future-proof Standard Library

With the standard library now compiled using Scala 3, it has been enhanced to better support two highly experimental language features. These features remain far from stabilization and should not be relied upon in production code.

Explicit nulls - When you enable explicit nulls in your project (-Yexplicit-nulls), all reference types become non-nullable unless annotated with | Null. Library maintainers have annotated many standard library APIs with explicit null-return types, so the type checker will now warn if you forget to handle a possible Null.

Capture checking - The library code has been adjusted to interact properly with the experimental capture-checking system. When you enable capture checking (-language:experimental.captureChecking) the type checker tracks references to capabilities and ensures you do not capture local resources in closures.

Note: Both null-safety and capture-checking annotations remain experimental, opt-in features. Your existing code will behave exactly as before unless you enable the appropriate language flag.

Pure functions and capture checking

The scala.caps.Pure capability is used by the capture checker to model pure functions. Experimental separation checking is new in Scala 3.8 and ensures that closures do not capture resources, providing stronger guarantees about side-effect isolation. To experiment with capture checking, import scala.language.experimental.captureChecking and annotate your functions with the appropriate capabilities. Adding these annotations does not require enabling experimental features and it will not affect users who are not using capture checking.

Note: Only core traits related to capture checking and defined in the Scala Standard Library have been stabilized, as these have been proven to be stable. The capture checking itself is still an experimental feature.

New experimental features

The following features are provisional and subject to change or outright removal. Do not rely on them in production code yet.

Several experimental SIPs land in Scala 3.8. You can try them by importing the corresponding experimental language imports or using matching experimental flags to the compiler.

SIP-67: Strict equality pattern matching

Scala’s strictEquality is great at preventing nonsensical == comparisons, but it historically made some very common ADT pattern matches painful - especially for enums or case objects, because constant patterns are compiled using ==, which in turn requires a CanEqual proof.

SIP-67 introduces an experimental opt-in that makes “ADT-style” pattern matching work smoothly under strictEquality, without forcing you to provide CanEqual evidence just to match on enum cases / case objects. In particular, it targets the frustrating situation where == should remain rejected (e.g., because parts of the ADT shouldn’t be comparable), yet match should still be usable.

import scala.language.strictEquality
import scala.language.experimental.strictEqualityPatternMatching

enum Foo:
  case Bar
  case Baz(f: Int => Int)

// Still rejected: comparing Foo values with `==` can be nonsensical
def eqIsStillIllegal(x: Foo, y: Foo) =
  x == y // error (as intended)

// But pattern matching is now practical under strictEquality:
def eval(x: Foo): Int =
  x match
    case Foo.Bar      => 0
    case Foo.Baz(fun) => fun(0)

This keeps the core promise of strictEquality (“don’t let me compare things that shouldn’t be comparable”) while removing a major adoption blocker for real-world enums and ADTs.

SIP-70: Flexible Varargs

SIP-70 removes a long-standing limitation of Scala varargs calls: you can now use * (spread) more than once in a single argument list, and the spreads can appear in the middle, not just at the end of arguments list. This makes it much easier to build varargs calls from multiple collections without manual concatenation.

import scala.language.experimental.multiSpreads

def sum(xs: Int*): Int = xs.sum

val a: Seq[Int] = Seq(1, 2)
val b: Array[Int] = Array(3, 4)

val total = sum(0, a*, b*, 5)   // 15

SIP-75: Allow single-line lambdas after `:`

The indentation based and fewer-braces syntax introduced in Scala 3 allows you to apply a method or operator by separating it from a block with a :. SIP-75 extends the supported syntax by allowing the body of the function to be defined in the same line after :. In this form, the lambda extends to the end of the line, making it easy to move between the indented and single-line styles without having to switch back to parentheses. The change is primarily about consistency and refactoring ergonomics:

You can read : uniformly as “application” when it is followed by either an indented block or a lambda.
It becomes natural to split/merge lines as code grows or shrinks, without changing the delimiter style (parentheses vs :)
The requirement of new line in the lambda body was confusing to users

import scala.language.experimental.relaxedLambdaSyntax

def newSyntax(xs: Option[Int]) =
  xs.map: v => v + 1
    .filter: v => v > 3 && v < 8

def oldSyntax(xs: Option[Int]) =
  xs.map: v =>
    v + 1
  .filter: v =>
    v > 3 && v < 8

Match expressions with sub-cases #23786

This change adds an experimental extension to pattern matching: a case in a match can be followed by a nested “sub-match” introduced by the if keyword. This feature enables you to:

first match an “outer shape” (e.g., Some(x)), and then
immediately refine the result by matching on a field derived from the outer bindings (e.g., x.version).

Crucially, if the nested pattern does not match, we still proceed to the next enclosing case. This is fundamentally different than putting the sub-case within another level of nesting—in a traditional nested match, a failed inner case would not cause the outer match to try subsequent cases.

import scala.language.experimental.subCases

enum Version:
  case Legacy
  case Stable(major: Int, minor: Int)

case class Document(title: String, version: Version)

def versionLabel(d: Option[Document]): String =
  d match
    case Some(doc @ Document(_, version)) if version match
      case Version.Stable(m, n) if m > 2 => s"$m.$n"
      case Version.Legacy                => "legacy"
      case _                             => "unsupported"
    case _                               => "default"

The sub-cases are tested only if the outer case matches (here: Some(Document(_, version))).
The sub-match scrutinee (version) can refer to variables bound by the outer pattern (doc).
Sub-matches do not have to be exhaustive. If none of the sub-cases match, the whole case ... if <submatch> is treated as not matched, and the outer match continues with the next case.
Sub-matches can be nested (sub-sub-matches), and you can interleave additional boolean guards between them when needed.

This experimental feature has not yet been considered by the SIP committee, but we’d like to hear your feedback about this proposal.

Other notable changes

Annotations can now annotate themselves #24447 - Scala now allows an annotation class to be annotated with itself. This is useful for “meta-annotations” where you want the annotation’s own definition to carry the same marker it applies elsewhere.

import scala.annotation.StaticAnnotation

final class audited extends StaticAnnotation

@audited                 // now allowed: the annotation annotates itself
final class audited extends StaticAnnotation

LTS/Next series indicators #24709 - Starting with Scala 3.3, all artifacts are published with a special attribute in the pom.xml. This attribute indicates whether a given version is part of the LTS or Next series. Tooling can use this information to adjust its behaviour. Starting with Scala 3.8 and the upcoming 3.3.8 LTS, the attribute name has changed from scala.versionLine to info.scala.versionLine. The change was required due to a negative interaction with build tools that assume attributes starting with scala are reserved.
Nightly builds in a new repository - Scala 3 nightly builds for both Scala Next and Scala 3.3 LTS series are now published to a new repository: https://repo.scala-lang.org/. You can read more about this change in a dedicated blogpost.
JDK 26 support - Scala can now emit and consume JDK 26 bytecode. As mentioned earlier, the internal implementation of lazy vals has been adjusted to replace the deprecated sun.misc.Unsafe with VarHandles. Starting with JDK 24, sun.misc.Unsafe emits runtime warnings. In JDK 26, it will throw an exception. This change makes newly published code compatible with JDK 26. However, these problems might still be triggered by previously published libraries or their transitive dependencies. We are working on tools to modify existing lazy-vals-related code to make them future-proof and ease migration to upcoming JDK versions. For more details, see the technical discussion in Jakub Kozłowski’s latest podcast with Łukasz Biały, VirtusLab’s Scala Advocate who prototyped this idea.

Tooling support

Scala 3.8 changes how parts of the standard library and the REPL are published, which can affect build tools and IDE integrations. For the smoothest upgrade, use the recommended versions (especially if you rely on the REPL).

Build tools

sbt
- Minimum sbt 1.11.5 (no REPL support)
- Recommended sbt 1.12.0
Mill
- Minimum mill 1.0.5 (or mill 0.12.16 on the 0.12 line) (no REPL support)
- Recommended mill 1.1.0(*forthcoming available 1.1.0-RC4)
Scala CLI
- Minimum scala-cli 1.9.0 (no REPL support)
- Recommended scala-cli 1.11.0

IDEs and developer tools

IntelliJ IDEA: Recommended Scala Plugin 2025.3. The JetBrains team has also prepared a blog post showcasing IntelliJ support for Scala 3.8.
Metals: Recommended: Metals 1.6.4
scalafmt: Minimum scalafmt 3.10.1
Scalameta: Minimum: scalameta 4.14.1 (used by Metals, scalafmt, scalafix, and more)

What’s next?

The language is now in feature freeze mode in preparation for Scala 3.9 LTS. No new language features will be accepted for 3.9. Development and improvement of existing features is still allowed. This allows us to focus on fixing existing bugs in both tooling and compiler to ensure a smooth transition into the Scala 3.9 LTS era. The freeze will be lifted with the start of the Scala 3.10 development cycle.

Effectively, Scala 3.9 LTS would contain the same feature set as Scala 3.8. We may promote preview features to stable, but no new experimental or preview features will be introduced. As a result, any codebase using Scala 3.8 should not require any additional changes to use Scala 3.9 LTS.

Scala 3.8.2-RC1 is already available and its stable version is expected to be released in the second half of February 2026.

Scala 2.12.21 is now available!

2025-12-11T00:00:00+01:00

Scala 2.12.21 is now available!

This release is compatible with JDK 25 LTS and also introduces preliminary support for JDK 26.

For all the details, refer to the release notes on GitHub.

Scala Days 2025: Conference Highlights and Talk Recordings

2025-11-26T00:00:00+01:00

This summer, the Scala Center celebrated 15 years of Scala Days, returning this August to its birthplace: Lausanne, Switzerland. The recordings of all the talks are now available on the Scala Days YouTube channel, and with that, here are some closing remarks, and a look ahead to the future.

The theme Functional Programming And The Real World attracted 57 excellent talks, and with 5 workshops, 27 sponsors, around 300 attendees, including several co-located events, the town was buzzing with Scala energy. We heard that in a bar far from the conference center, a local bartender proudly welcomed Scala enthusiasts after spotting the logo on their T-shirts and, to everyone’s delight, replied:

“Of course we know Scala, it was designed here at EPFL!”

Even the journey was part of the fun: thanks to the London Scala User Group, attendees boarded the Scala Jam Train from London through Paris — a rolling meetup that brought the community together before the first talk even began.

This wonderful experience was only possible thanks to the many hands and hearts behind the scenes and on the stage.

Attendees — for your questions, hallway conversations, and enthusiasm that filled Lausanne with Scala spirit.
Organizers — for months of planning, coordination, and care that made it all seamless.
Program Committee — for building such a thoughtful lineup.
Speakers — for sharing your knowledge, passion, and curiosity.
Sponsors — for your generous support and commitment to the Scala community, helping make Scala Days possible.
Volunteers — for your energy, kindness, and problem-solving superpowers.

We thank you all ♥️

All Talks Now on YouTube 🎥

We knew choosing between four parallel tracks would be tough — and that’s exactly the feedback we heard throughout the week! Good news: all talks and keynotes are now available on the Scala Days YouTube channel. Relive the insights, learn something new, or discover what you missed.

🎯 Panorama Track – a grand tour of the Scala ecosystem: language evolution, tooling innovation, and community discussions.

🏢 Industry Track – real-world stories from teams running Scala at scale, exploring lessons learned and business impact.

💡 Developer Experience Track – deep dives into tooling, productivity, and how to get more out of your daily Scala flow.

🎨 Creative & Mix Track – a vibrant mix of technical talks, playful experiments, and unexpected ways Scala shows up in life and work.

Building Trust: Inclusion, Safety, and Community

At the Scala organization, we aim to build trust in Scala as an open source software project by providing regular releases, clear governance and open processes. Beyond the codebase we work to cultivate trust by making Scala Days a welcoming and inclusive space where community members can learn, share, and engage professionally in a safe environment. This year’s conference strengthened this commitment by focusing further on these key areas:

Safe environment An updated Code of Conduct and on-site expert support team were available throughout the event, and many attendees took the opportunity to learn more about these resources. Organizers and volunteers trained in advance, speakers received dedicated briefings, and all attendees were oriented before the conference began — ensuring that everyone, from first-timers to long-time participants, felt encouraged and equipped to contribute to a culture of safety.

Inclusive by design Inclusion by design starts with infrastructure. This year we ensured full accessibility across the conference experience while continuing to invest in thoughtful, community-specific details: a quiet room, a tourist information point, and volunteers ready to assist. We also provided on-site childcare and encouraged participants to bring partners and families, making Scala Days a shared experience.

Community building Our conference-wide icebreaker game, Find Your Twin, gave everyone a simple, playful starting point to meet new people and begin building connections. Colocated social activities and informal gatherings throughout the week further supported this. A highlight for many was the Community Party at the Museum of Modern and Contemporary Arts (MUDAC), where attendees could stroll through exhibitions, spark fun informal conversations — a relaxed setting for getting to know one another and deepening community connections.

Program flow We understood that with so many fantastic talks, it could be tough for our attendees to organise their day around which talks they wanted to see the most. To support this, we organized the agenda into four thematic tracks, giving attendees clearer pathways through the content. And through the speaker buddy program and other coordination efforts, speakers were encouraged to learn about related sessions and, when appropriate, highlight those connections during their talks that helped guide attendees toward topics most relevant to their interests.

We hope that these efforts played a part in the remarkable outcome that nearly 50% of attendees were joining Scala Days for the first time — a promising indicator of renewed trust, openness, and growth.

Looking Ahead

As we wrap up this year’s Scala Days, and thanks to your feedback, we already have many ideas about how to further enhance the conference experience: from business-driven opportunities to deepen industry engagement, to new formats that elevate technical learning, networking, and collaboration.

Please stay tuned for Scala Days 2026 as we have announcements coming soon! Until then, keep learning, keep sharing, and keep Scala vibrant.

One More Thank-You to Our Sponsors

Your support keeps Scala Days thriving and the Scala community growing.

🌟 Platinum Sponsors

VirtusLab – The company behind Scala. VirtusLab showcased its long-standing commitment to the Scala ecosystem — from contributing to the language itself and developing key tools like Scala CLI and Metals, to building popular Scala OSS libraries. Their focus on developer productivity, IDE and Bazel expertise, and LLM-assisted workflows, combined with the efficient delivery of high-quality software solutions for numerous partners, reflects their 15+ years of leadership in Scala innovation.

Signify Technology – Building a diverse future, one placement at a time. As a global Scala recruitment specialist, Signify connects top-tier engineering talent with forward-thinking companies. With offices in LA, Austin, and London, they continue to champion diversity and inclusion in tech hiring worldwide.

🥇 Gold Sponsors

Gradle – Accelerate every Scala build. Gradle’s Develocity platform now integrates with sbt to help teams observe, optimize, and speed up their builds — empowering faster feedback cycles and better developer experience.

JetBrains – Easier and smarter software development. JetBrains has supported the Scala community for many years. This time, the IntelliJ Scala Plugin team came to Scala Days to present the AI-powered tooling JetBrains offers for developers, along with both new capabilities and long-standing hidden gems of IntelliJ IDEA and the Scala Plugin. Together, these tools help developers boost their productivity and make everyday Scala development more enjoyable.

Scalac – Your Scala & AI engineering partner. With 11 years of expertise and over 130 delivered projects, Scalac continues to champion open source, community growth, and global partnerships. They invite you to explore the latest trends shaping Scala’s future, check out their State of Scala Report—a comprehensive look at the ecosystem’s direction, challenges, and opportunities ahead.

Writer – Where AI meets business. Writer showcased its agent-builder platform that bridges IT and business teams, offering tools to build, activate, and supervise enterprise AI agents — and invited Scala engineers to join their growing AI research and engineering efforts.

Xebia – Engineering excellence, powered by Scala and AI. Xebia reignited its Scala community presence with demos, workshops, and hands-on sessions on event-sourced domain modeling and domain-driven design in Scala 3.

Kpler – Scala powering data at scale.For over a decade, Kpler has been building high-performance applications powered by the Scala ecosystem — leveraging its strong type system, functional programming paradigm, and thriving community. At Scala Days, they shared their journey and commitment to contributing back to the community.

🥉 Bronze Sponsors

A warm thank-you to our Bronze sponsors for their continued support of Scala Days and the wider community: Scala Teams, Mastercard, MOIA, Les Toises, Rock the JVM, ngrok, YouMoni, DFiant Works, Snowplow Analytics, SoftwareMill, Tiko, Recorded Future, SwissBorg, Deltek, HES-SO Valais-Wallis, Artima, NuMind, SiriusXM, and Netflix.

A special thank-you to EPFL, the birthplace of Scala, for hosting Scala Days 2025 and welcoming the community. From the lecture halls where Scala was first conceived to today’s thriving academic and industry ecosystem, EPFL continues to nurture the language’s growth and spirit.

Scala 2.13.18 is now available!

2025-11-24T00:00:00+01:00

Scala 2.13.18 is now available!

This release fixes several regressions from 2.13.17. It is compatible with JDKs 8 to 26.

For details, refer to the release notes on GitHub.

The Scala Programming Language

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

How to report future security issues

Thank you

Participation

Scala Days 2026: Call for proposals open

Scala Days 2026: Call for proposals open

Formats

Talks (30 minutes)

Interactive Labs (2 hours)

Workshops (2 days)

Topics

Experience & Industry

Data & AI

Development

Tooling

Foundations

Community

Other Areas

Strategic & Forward-Looking Topics

Get inspired

Last mile towards sbt 2

What’s new in sbt 2?

Repopulating the plugin ecosystem

Tooling support and documentation

Locking down to 2.0.x branch

Participation

Fixing a Command Injection Vulnerability in sbt

The vulnerability

Severity

The fix

Workflow of applying the fix

Applying the fix

Participation

Scala 3.8.3 is now available!

Scala 3.8.3 is now available!

Release highlights

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

Safe mode for capability-safe code (#25307)

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

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

Announcing Scala Days 2026

Co-located events

Meet Plain Schwarz

Call to action

Porting the Scala 2 optimizer to Scala 3

Optimizing for the best of both worlds

Limitations

Using the optimizer

Future directions

Participation

Hardening Scoverage Support in Scala 3

Summary

Background

Enabling coverage on the compiler test suite

Addressing breakages: erased values and the purity constraint

Expanding the testing surface

Conclusion

Participation

Migrating sbt plugins to sbt 2 with sbt2-compat plugin

The PluginCompat Pattern

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

1. Add sbt2-compat to your plugin

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

Project status

Participation

Scala 3.8.2 is now available!

Scala 3.8.2 is now available!

Release highlights

Warning for for with many vals and overloaded map (#25090)

Notable changes

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

`: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)

SIP-57: Replace non-sensical `@unchecked` annotations

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

SIP-75: Allow single-line lambdas after `:`