Scala Release Notes

Scala 3.10 released!

We are happy to announce Scala 3.10.0, the first release of the new Scala Next series.

This release stabilizes SIP-67, moves three SIPs into preview, and starts dropping legacy language features that have been deprecated for several minor releases.

Scala 3.3 LTS and Scala 3.9 LTS put compatibility with Scala 2.13 first. Now, nearly five years after Scala 3.0, Scala 3.10 starts removing legacy syntax and features that have been deprecated for several minor releases. The standard library also starts using more Scala 3 features, such as inline and extension methods.

Binary compatibility is preserved: libraries compiled with earlier Scala 3 versions keep working, including those that used features now removed. Source that still uses those features must be updated to compile with 3.10. Macros and compiler plugins may need to be adapted to changed internal representations (details below). If you publish a library and want the longest support window, Scala 3.9 LTS remains the recommended version to build against.

Cross-compilation between Scala 2 and 3.10 is no longer supported because of the removed legacy features. Some libraries might remain cross-compilable, but it is expected that cross-compiled libraries will remain on Scala 3.9 LTS indefinitely.

Before checking a 3.10 artifact with MiMa, upgrade to MiMa 1.2.1 or later: that release adds Scala 3.9 and 3.10 support and fixes several false positives.

Highlights

• SIP-67: pattern matching under strictEquality no longer needs CanEqual - now stable. (But strict equality remains an opt-in feature.)
• Three SIPs move to preview behind -preview: @unroll, relaxed lambda syntax, and referenceable package objects.
• Deprecated syntax previously retained for compatibility with Scala 2, such as A with B, is now an error; see Breaking changes.
• The compiler reports Recursion limit exceeded instead of crashing with a StackOverflowError (details).
• Scala is now also distributed as .deb and .rpm packages.

Breaking changes

Most projects can upgrade without code changes. Macros and compiler plugins are affected most, but not exclusively. Expect problems in a few areas:

• APIs that were easy to rely on by accident (for example, a given defined in a private companion object, or a custom -> defined via an implicit class)
• Syntax that has been deprecated for several releases already
• Standard library operations that became inline or extension methods for performance. Normal call sites are unaffected, but macros see different trees, so you usually just need to upgrade the affected library.

The sections below walk through the most common issues in more detail.

Library maintainers: if you ship macros or compiler plugins, add a CI job that builds against Scala Next nightly releases (or against release candidates once they are available). Several of the fixes listed below were found by the Open Community Build; a job in your own repository finds such problems earlier.

Inaccessible companion implicits are no longer found

When implicit search looks into a type’s companion, it now only considers instances that are accessible at the call site. Scala 3.9 already reported this under -deprecation; Scala 3.10 stops finding those instances.

The specification has always required an eligible implicit to be accessible at the point of the call. If a library you maintain still hides givens in a private companion, publish a fix before users move to 3.10 - users usually cannot work around it in their own code. Make the companion public, or move the given to a public object.

Stronger constant folding during inlining

Stronger constant folding during inlining fixes several inlining bugs, but it also makes compilation fail for macros that generate ill-typed code, which previously happened to work. Scala 3.10 also checks that a macro expansion has the type the macro claimed.

If you use the ZIO ecosystem, upgrade these libraries before upgrading the compiler. The fixed versions are:

• ZIO 2.1.26
• zio-blocks 0.0.54
• izumi-reflect 3.0.10
• neotype 0.7.2, which also covers the Rich* change below

Primitive Rich* wrappers are extension methods

runtime.RichInt and the other Rich* implicit classes are gone. Operations such as until, to, abs, and max are now extension methods defined in the companion objects of Int, Long, and the other primitive types. Call sites that just use 1 to 10 keep working. Macros that inspected the old Rich* symbols, or that assumed Predef still inserted those implicit classes, need to match the extension-method shape instead.

-> is an inline extension method

The a -> b pair syntax is now an inline extension method. Predef.ArrowAssoc is deprecated and is no longer an implicit conversion.

Two practical consequences:

• Quote patterns such as case '{ ($a: String) -> ($b: Any) } no longer match, because the tree is no longer an ArrowAssoc conversion.
• If your library defines -> through an implicit class, Predef.-> may now be chosen instead, because extension methods and implicit classes are prioritized differently (#26851). A -> defined as an extension method still takes precedence. If you ship a DSL that defines -> via an implicit class, change it to an extension method.

A with B is an error

with as a type operator has warned since Scala 3.4 and is an error in 3.10. On Scala 3.10, -source:3.4-migration -rewrite rewrites A with B to A & B. In typed patterns, the intersection must be wrapped in parentheses: case x: (A & B) =>. The rewrite adds them for you.

this is illegal in top-level definitions

Top-level definitions using this are now rejected (#26448). A top-level definition has no enclosing class, so this has nothing meaningful to refer to. Previously the reference resolved to the synthetic package object for the file, which was almost never what authors intended.

Java generic signatures are more precise

The compiler now uses boxed types for primitive type arguments in the generic signature stored in class files (#25944). For a type such as Option[Int => String], the generic signature is now more precise.

The JVM method descriptor is unchanged, so Scala binary linking keeps working. What changes is what Java compilers and bytecode tools read from that signature. MiMa may report IncompatibleSignatureProblem when you republish (#27063 is one example); use MiMa 1.2.1 or later, as noted in the introduction. If you mix Scala and Java, also check that Java call sites still type-check against the tighter signature.

Primitive and value-class results inside higher-kinded type lambdas are now boxed as well; previously they could crash the compiler’s JVM backend (#26787).

Recursion runs out of “fuel” instead of overflowing the stack

The compiler no longer catches StackOverflowError to stop runaway type checking (#25937). Very deep types that used to compile may now fail until you raise -Xmax-fuel and usually -Xss. See Fuel-limited recursion for how that works and which flags to set.

Other compatibility notes

• Deprecated no-op compiler settings are removed, including -Youtput-only-tasty (#26169, #26170, #26171).
• Bytecode generation uses the stock ASM library instead of the scala-asm fork (#26772). Tools that depended on the scala-asm artifact transitively may need a dependency update.

New stable features

SIP-67: Strict equality pattern matching

With strictEquality, x == y needs a CanEqual instance, so you cannot compare unrelated types by accident. Until now that also got in the way of ordinary pattern matching: matching on an enum case or case object is implemented with == under the hood, so the compiler asked for CanEqual even when you only wrote match.

SIP-67, experimental since Scala 3.8, is now stable, so it applies whenever strictEquality is enabled. You can match on enums and ADTs under strictEquality without proving CanEqual, while == itself stays strict.

New preview features

Preview features are enabled with -preview (for example scalacOptions += "-preview" in sbt, or scala -preview / //> using options -preview with Scala CLI). The experimental language imports that previously gated these SIPs are deprecated; using them prints a warning that points you to -preview.

SIP-61: Unroll default arguments

Adding a parameter with a default value to a public method is source compatible, but not binary compatible: the old JVM method signature disappears, so code compiled against the previous version of your library fails at runtime with NoSuchMethodError. @unroll tells the compiler to keep the old signatures as forwarders - methods that exist in the bytecode but cannot be called from Scala source.

New parameters must be appended. @unroll marks the first parameter added in each version of your library, and every parameter to its right must also have a default. The compiler checks that annotated parameters (and those after them) have defaults. The compiler does not check that @unroll is placed at the right version boundary; that is your responsibility. Keep an @unroll at every previous binary boundary when you add another wave of parameters.

New Scala callers compiling against the latest version of the API do not need the forwarders: they see the full method and omit trailing arguments via ordinary Scala defaults. The forwarders exist for already-compiled clients that linked against an older JVM signature such as greet(String). Without @unroll, defaults alone never emit those older overloads, so old binaries fail to link. You can append parameters this way, but you cannot remove them later: dropping a parameter removes a binary entry point and breaks existing callers. Use MiMa against your previous artifacts to catch a missing forwarder or a dropped parameter before you publish. If v1.2 had annotated only color, the v1.1 entry point greet(name, excited, punctuation) would be kept but the v1.0 entry point greet(name) would be lost.

SIP-75: Relaxed lambda syntax

Fewer-braces application with : already allowed an indented lambda. SIP-75 now allows the lambda on the same line as well, so : means application whether the body is indented or written inline. A same-line lambda extends to the end of the line. Placeholder syntax (_) is not supported; write a lambda with named parameters and => or ?=>. For example, xs.map: _ + 1 is rejected; write xs.map: x => x + 1 instead.

In both forms above, .filter continues the chain started by xs.map; the indentation of the lambda body does not change how the following .filter attaches. Two single-line lambdas on the same line are rejected (SIP amendment): xs.map: x => ys.map: y => x + y must wrap the inner lambda in parentheses. The new rule also does not apply immediately inside parentheses, so (x: Int => Int) stays a type ascription.

SIP-68: Referenceable package objects

You could always call members on a package object (lib.json.encode(...)), but until now you could not treat the package object itself as a value the way a normal object works. val api = lib.json failed with “package is not a value”; the workaround was lib.json.package. SIP-68 removes that irregularity, so the direct form now works.

Package objects are listed among features that may eventually be dropped, but there is no concrete plan to remove them. Until there is, they should behave like ordinary objects.

lib.json is treated as lib.json.package only when it is used on its own, not in a longer selection such as lib.json.encode. Its type is the type of the package object, so it only includes members of the package object itself, not top-level definitions from other files in the same package.

New experimental features

Experimental features carry neither source nor binary compatibility guarantees between any compiler versions. They can be changed or removed at any time until stabilized as preview features. Enable them with -experimental, or with a specific -language:experimental.* option as in the snippets below. A Pre-SIP feature is a design that has not yet been submitted as a SIP.

SIP-72: Dedented string literals

Dedented string literals are an experimental implementation of SIP-72. Enable them with -language:experimental.dedentedStringLiterals, or import language.experimental.dedentedStringLiterals.

They introduce a ''' multiline literal that strips indentation in the language, so you do not need .stripMargin. The opening ''' must be followed by a newline, and the closing ''' must sit on its own indented line. The compiler removes the first newline after the opener, the final newline before the closer, and common leading indentation up to the closer’s column. Indent content further than the closer if you want leading spaces kept in the string. Interpolators such as s'''...''' and f'''...''' work the same way.

Pre-SIP: Inline traits and specialized traits

Inline traits and specialized traits are a new attempt at specialization in Scala 3, a Scala 3 successor to Scala 2’s @specialized, which Scala 3 does not support.

An inline trait does not stay as a shared superclass whose methods are erased to Object. When a concrete class extends Cell[T] with T = Int, the compiler copies the trait’s members into that class with T already replaced by Int, so the implementation stores and returns a primitive int.

That alone is not enough for calls through a reference whose static type is Cell[Int]: erasure would still see a generic Cell interface, so c.get would return Object and need unboxing. A Specialized context bound asks the compiler to also emit a specialized interface (for example Cell$$sp$scala$Int with get(): Int) and to route those calls through it, so bump reads the value without boxing (an unboxed get followed by iadd, instead of get, unboxToInt, iadd).

See the reference for the generated layout, richer examples such as specialized numeric vectors, and the current restrictions.

Scala CLI and distribution

Scala 3.10 ships with Scala CLI 1.17.1. See the v1.17.0 and v1.17.1 notes for the full list; the main additions are:

• Java instance main methods and void main() without a class (JEP 512), on JDK 25+ (or JDK 21+ with --enable-preview)
• Individual files as resources with --resource or //> using resource
• //> using exclude in .sc scripts
• Passing a -d path ending in .jar now produces a library JAR, as scalac does
• The lts version tag now resolves to the Scala 3.9 LTS series (use 3.3.lts to stay on 3.3)

Deb and RPM packages

The recommended way to install Scala remains a version manager such as Coursier, SDKMAN!, or Homebrew. Those tools still give you the easiest upgrades and the ability to switch between Scala versions.

Scala 3.10 also ships the distribution as .deb and .rpm packages (#26858), so you can install it through the usual package managers on Debian/Ubuntu and Fedora/RHEL-family systems when that fits your environment better. The packages are published as GitHub release assets alongside the existing archives, the same way Windows .msi installers are.

Other changes worth noting

Fuel-limited recursion

Deep or recursive types used to make the compiler overflow the JVM stack. Catching StackOverflowError was unreliable, and the crash was hard to relate back to your code.

From Scala 3.10, recursive compiler work spends fuel (#25937): a counter of how deeply the compiler may nest fuel-checked operations such as subtype tests, match-type reduction, or inlining before it gives up. Each nested entry costs one unit of fuel; when the counter hits zero, compilation stops with Recursion limit exceeded and a short list of the recurring operations, instead of a stack overflow.

The fuel budget is set with the compiler option -Xmax-fuel. The default is 550, chosen so that, with a typical JVM stack size, the compiler runs out of fuel before the stack overflows. If the error comes from a type or expansion that is meant to be that deep, raise the limit, for example -Xmax-fuel:2000, and give the compiler a larger stack with -Xss (in sbt, put it in .jvmopts; with Scala CLI, //> using javaOpt -Xss8m or --java-opt -Xss8m). Raising fuel without raising the stack often just turns the error into a real StackOverflowError.

Fuel is separate from -Xmax-inlines (default 32), which caps how many successive inline expansions are allowed. Deep recursive inlines also spend fuel while the expansion is typed, so raising -Xmax-inlines alone may still fail with Recursion limit exceeded until you raise -Xmax-fuel (and usually -Xss) as well.

If you get a StackOverflowError on 3.10 without changing -Xmax-fuel or the stack size, that is a compiler bug: fuel should run out first. Please report it.

For the details, including hosts where you cannot grow the stack when the compiler itself runs there, see Compiling deeply nested code.

Pattern matching on Java records

Java records can be used as extractor patterns, including generic records and varargs components (#26497). A static unapply already defined on the record class still takes precedence.

Given these Java records, compiled as part of the same project or coming from a dependency:

\s space escape

String literals accept \s as a space, including in interpolators (#26515). raw"..." still treats the two characters literally.

REPL

You can now type //> using dep, //> using toolkit, and //> using jar directives directly in the REPL, on their own or followed by code in the same input (#26507, #26788, #26726). Do not mix them with : REPL commands in a single input.

The REPL also gained :save and :replay: :save writes the session’s inputs to a file, and :replay resets the REPL and re-runs those commands. -Yrepl-print-tostring (#26435) prints results with toString instead of the default pretty-printer. -deprecation and -feature are enabled by default in the REPL.

Standard library and tooling

• IArray now has Factory, IsSeq and BuildFrom instances (#24552, #24674), so more collection operations work without converting to Array.
• Several standard-library collection operations allocate less; ArrayDeque.clear is now O(1) (#26288).
• Scaladoc no longer crashes on mixed class/module API packages, keeps the current page when switching versions, and finds members whose names end in ! or $.

What’s next?

The release branch for Scala 3.10.1 has already been cut, and its first release candidate will follow shortly.

We plan one further patch, Scala 3.10.2, a few weeks later. After that, development moves on to Scala 3.11, expected around March or April 2027.

Scala 3.9 LTS continues as the long-term publishing baseline.

As always, the full changelog is available in the release notes on GitHub.

Original source

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.

Plugin as an ecosystem

Out of the box, sbt handles basic functionality like building and testing Scala code. Once you get used to the basics, the build can be extended further by using community plugins. Plugins range from simple utilities to support for new programming languages.

One aspect of a plugin project is that it can be created and developed without waiting for a release of sbt, so it’s a great way to try new ideas or collaborate across the community. If you want to discover plugins two sources are:

• Community Plugins page
• Scaladex

Preparing for reforestation

Since the ecosystem is an essential element of the user experience, the health of the plugin ecosystem is always our concern. This is especially so when we release a new major version, which burns the old forest. All plugins need to be cross built, and re-published, like new saplings springing from the ash. There are several strategies we adopted to aid the reforestation.

• Over the years, we have centralized major plugins to GitHub sbt organization. This lets us add new maintainers to the plugin who can review the PRs.
• Created the sbt 2.x plugin migration wiki page to coordinate the migration effort.
• We locked down the ABI for 2.x with 2.0.0-RC1, which was released in August 2025. This gave a head start for the plugin authors to cross publish before sbt 2.0 came out.
• In March 2026, Anatolii Kmetiuk (Scala Center) created sbt2-compat plugin, which adds a compatibility layer so that the same plugin can target both sbt 1 and sbt 2.
• Beyond tooling, we’ve actively sent pull requests to migrate the plugins.

I’m happy to report that as of this writing (September 2026), Scaladex lists 172 plugins available for sbt 2.x. Many thanks for the community effort by volunteers like Kenji Yoshida and many others.

In this post, I’d like to highlight some of the most notable plugin updates.

Plugin updates

Scala.js 1.22.0

Scala.js 1.22.0 shipped with sbt 2.x support. Rikito Taniguchi (VirtusLab) sent scala-js#5314 on behalf of the sbt project to port the plugin to sbt 2.x.

Side note: A test included in the pull request mentions the fact that in sbt 2.x %%% operator is no longer needed, which is nice:

// In sbt 2, %% resolves to the Scala.js artifact (scalajs-dom_sjs1_3)
// for Scala.js projects. This replaces the %%% operator from sbt 1.
libraryDependencies +=
"org.scala-js"
%%
"scalajs-dom"
%
"2.8.0"

sbt-matrix-sources 0.1.0

There’s a new plugin for sbt 2.x called sbt-matrix-sources, created by Albert Meltzer. This plugin adds /src/main/ to the source directory like js/src/main/scala. This provide an sbt-crossproject emulation on top of the project matrix to smooth out the sbt 2.x migration.

sbt-git 3.0.0-RC1

sbt-git 3.0.0-RC1 was published recently for sbt 1.x and 2.x. sbt-git 3.x features a shift to use system git by default as opposed to JGit. This was contributed by Matthias Kurz, from the Play framework project.

sbt-buildinfo 0.13.2

sbt-buildinfo 0.13.2 was published recently for sbt 1.x and 2.x. sbt-buildinfo is a small code generator that I created a while back to give project code access to information in the build definition. sbt-buildinfo 0.13.2 features a bug fix contributed by Lukas Rytz (VirtusLab) that should avoid running the tasks out-of-graph on sbt 2.x.

sbt-github-actions 0.32.0

sbt-github-actions 0.32.0 was released a few weeks ago for sbt 1.x and 2.x. sbt-github-actions generates GitHub Actions YAML files from the build. sbt-github-actions 0.32.0 features an update that I sent to use actions/setup-java v6.

sbt-assembly 2.5.0

sbt-assembly 2.5.0 was released a few weeks ago for sbt 1.x and 2.x. Recent contributions include an update to make shading errors fail the build, by Stas Shevchenko (Evolution), and artifact caching, by Dmitrii Naumenko (JetBrains).

sbt-salad-days 0.2.0

sbt-salad-days is a plugin I created to reduce the Scaladoc JAR size for Maven Central publishing. This is an interim solution while we wait for a fix to be merged upstream in various Scala versions.

sbt-site 1.8.0

sbt-site 1.8.0 was cross published for sbt 1.x and 2.x last month. sbt-site is an sbt plugin originally created by Josh Suereth to generate project websites. I sent sbt-site#224 to cross build it.

sbt-testng 3.2.0

sbt-testng 3.2.0 was cross published for sbt 1.x. and 2.x recently. I’m not sure how popular testng is, but I sent sbt-testng#30 to aid Slick migrating to sbt 2.x.

sbt-pgp 2.3.2

sbt-pgp 2.3.2 was released last month for sbt 1.x and 2.x, with a fix to ensure compatibility with sbt 2.1.0.

Towards sbt 2.1.0 + Scala 3.9.0 LTS

Recently we published sbt 2.1.0-M1, kicking off the beta release of sbt 2.1.x series. Among the headline feature of sbt 2.1.0 is Scala 3.9.0 LTS on the metabuild. Since both sbt 2.x and Scala 3.x are backward compatible, generally existing plugins should continue to work.

• Since sbt 2.1.0 removes Apache Ivy as its dependency, any plugins that were using internal Ivy code should migrate to using the LM API (available since sbt 1.0), which abstracts over Ivy and Coursier.
• Since Scala 3.9.x will be better supported as Long Term Support (LTS), we should adopt it once sbt 2.1.0 becomes available. Until then, plugins must stick with Scala 3.8.x.

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.

Original source

Scala 3.9 LTS released!

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

What does LTS mean?

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

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

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

Looking back at Scala 3.3 LTS

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

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

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

What’s new in Scala 3.9?

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

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

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

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

Documentation snippets can declare the errors they expect

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

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

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

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

The rules are:

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

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

Scala CLI updates

Scala 3.9 updates Scala CLI, which brings new features:

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

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

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

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

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

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

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

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

Scala.js 1.22

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

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

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

The equivalent for Scala CLI is two directives.

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

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

Other improvements in Scala.js 1.22:

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

Inaccessible companion implicits will no longer be found in Scala 3.10

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

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

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

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

Other notable changes

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

Coming from Scala 3.3 LTS?

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

Scala 3.4

NEW STABLE FEATURES

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

BREAKING CHANGES

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

OTHER NOTABLE CHANGES

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

Scala 3.5

NOTABLE CHANGES

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

Scala 3.6

NEW STABLE FEATURES

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

BREAKING CHANGES

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

Scala 3.7

NEW STABLE FEATURES

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

BREAKING CHANGES

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

OTHER NOTABLE CHANGES

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

Scala 3.8

NEW STABLE FEATURES

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

BREAKING CHANGES

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

OTHER NOTABLE CHANGES

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

Migration guide

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

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

Recommended upgrade order

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

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

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

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

Compiler built-in rewrites

1. Pick a Scala compiler to run the rewrites on:
   • Start with Scala 3.7.4 if the codebase often passes explicit arguments to standard-library methods that now need using. 3.7.4 is the last release before the standard library was compiled with Scala 3, and it can insert those using clauses before the 3.8 library boundary.
   • Start with Scala 3.9.0 if the codebase uses a lot of with types. 3.9 improved the rewrite of with to &; the same flags on 3.7.4 could emit code that does not compile.
2. With that compiler, apply the -source:3.x-migration rewrites in order for each minor you are crossing, always with -rewrite: -source:3.4-migration, -source:3.5-migration, -source:3.6-migration, -source:3.7-migration, -source:3.8-migration, then -source:3.9-migration.

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

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

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

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

Scala 2.13 consumers via TASTy Reader

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

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

Runtime reflection with scala-reflect

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

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

What you can do today:

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

What’s next?

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

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

A glimpse of what is coming:

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

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

Original source

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

TL;DR

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

sbt.version=1.12.15

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

The vulnerability

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

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

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

Global / serverConnectionType := ConnectionType.Tcp

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

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

The fix

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

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

AI tooling

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

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

Participation

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

See The Scala Center Fundraising Campaign for more details.

Original source

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

What’s new in sbt 2?

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

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

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

How do I get started with sbt 2?

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

sbt.version=2.0.1

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

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

Repopulating the plugin ecosystem

Major plugins are already available on sbt 2.x.

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

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

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

Client-server by default

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

$ sbt compile
$ sbt test

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

Project matrix

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

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

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

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

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

Using cross-published libraries

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

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

See Cross building and Cross building setup for more details.

Let us know what you think

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

Participation

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.

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

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

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

Original source

Scala 3.3.8 LTS is now available!

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

Notable changes

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

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

Scala LTS Release Notice

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

Original source