Scala 3.9.0-RC1 is now available for public testing!
Scala 3.9 is the next Long Term Support (LTS) release line, succeeding Scala 3.3 LTS.
Highlights of the release
-
Long Term Support — Scala 3.9 becomes the new LTS line
-
Make into type and modifier stable #26184 (SIP-71, previously a preview feature in 3.8)
What’s new since 3.8
Language and compiler behavior
-
Improved Java generic signatures — a large set of backend and transform fixes improves emitted Java signatures for HKTs, context functions, value classes, trait fields, and related cases. This improves Java interop and tooling that reads generic signatures.
-
Better diagnostics — actionable messages for missing members #23572, improved multiline argument error spans, and assorted parser/lint warnings (e.g. dubious negative literals, trailing colons on empty templates, dollars in definition names unless backticked).
-
Implicit search — equivalent implicit candidates are now treated as divergent #25910; implicit conversion to AnyRef is disallowed again #26210.
Tooling and developer experience
-
Scaladoc snippet testing — snippets can use compiler-style // error and // warn expectations in compile+test mode (via -snippet-compiler / snippetCompiler config). Example: some-doc.md=compile+test #25713
-
No automatic Main-Class detection — when compiling directly to a JAR, the compiler no longer scans for and auto-selects a main class for MANIFEST.MF. Use -Xmain-class explicitly if you need a Main-Class entry. Build tools (sbt, Scala CLI, etc.) typically set this themselves; this mainly affects direct -d out.jar workflows and incremental JAR compilation edge cases #25215
-
Automatic-Module-Name restored in the Scala 3 standard library JAR manifest — fixes JPMS module naming regressions from the 3.8 stdlib migration #26218
-
Scoverage — many fixes for interaction with capture checking, large methods, curried constructors, and related instrumentation issues.
We encourage trying out 3.9.0-RC1 and reporting found issues in the Scala 3 issue tracker.
Release schedule
- Stable 3.9.0 will ship no earlier than six weeks after RC1 — approximately July 22. We may delay further if stability requires it.
Once 3.9.0 is stable:
-
Scala 3.10.0 is the next Scala Next release — main (and nightly releases) already targets 3.10.0.
-
3.9.x patch releases continue on the 3.9 release branch, with selected fixes backported from Scala Next (3.10 and later) under the LTS backport policy.
See the full list off changes in the 3.9.0-RC1 changelog.
Please share feedback here or on GitHub issues. Happy testing!
9 Likes
I’d like to ask: for libraries like Akka, Pekko, Play, Cats, Kyo, and Zio—which currently support only Java 17—if a new LTS version is released, should the Scala 3 version be published using the 3.9.0 series or the 3.3.x series?
1 Like
If don’t need any of the features that arrived on 3.4+ (nor you need to do something to support them e.g. add some code to make your library work with named tuples) there is no downside for staying at 3.3. If you’re already targeting JDK17+, you might want to add -Yfuture-lazy-vals flag available since 3.3.8 though.
Thanks, not sure if the community will do a hard switch to Scala 3.9.x
3.3.x will only be supported for so long after the 3.9.0 release. I would understand libraries (especially foundational ones like the various async runtimes) taking their time to bump to 3.9.0, but everyone really should be switching before 3.3.x goes end of life.
1 Like
Why though? Will compiler stop compiling? Will existing code no longer link? Will it prevent usage from the downstream where you can have 3.10 and consume 3.3 forever?
If you are not using any of 3.4+ features, nor are held back by compiler bugs, all you do is forcing the downstream to update whether it’s convenient or not. Unsupported 3.3 would only become an actual issue if there was something like a security vulnerability, that library consumers couldn’t fix by just using a newer compiler than the one that compiled the library.
1 Like
The whole point of having old versions go EOL and getting people to upgrade is so that never happens. Is it terribly likely to happen? No. But encouraging libraries to build on an EOL Scala is how we end up getting rudely surprised if it happens.
I don’t think libraries should make a point of making a release just to bump to 3.9, but I don’t see a good reason to avoid updating on whenever they get around to minor release anyways, especially after 3.3 goes EOL. Why support a compiler version that isn’t supported by the vendor?
1 Like
What was the point of LTS?
Every time we had a major version bump on Scala 2 (2.11 → 2.12 → 2.13), we had a small extinction event when some libraries were no longer actively developed, but they worked, but without an active intervention of the maintainers the were lost and whole ecosystem got disrupted, and also everyone had to wait with releasing their new version until their upstream releases the new version.
Scala 3 introduced the backward compatibility guarantee, that whenever you use some minor version (3.3, 3.4, 3.5, …) all artifacts compiled on this minor version or all minor versions before it. Which is good.
However, now we were at risk that every time a new compiler version is released, everyone updates and we don’t have a mass extinction event every ~5-10 years but every 1.5 year. LTS was created purposefully to make library maintainers stay on a single low Scala version for years, so that downstream have no disruptions. Compiler updates and fixes on LTS are just a honeypot to make people not use a new shiny thing while rugpulling all their users by accident.
If a library does not need 3.4+, it can stay on 3.3 forever. It is irrelevant that the compiler will not be supported. Libraries that rely on it will be able to update at their own pace. Apps that relay on all of that will be able to update on their own pace. Authors could move to next LTS only once they make sure that majority of their users (both apps and libraries) are already there, which is surely a few years into the next LTS lifecycle.
Otherwise we aren’t encouraging community to update: we encouraging them to follow Apache Flink (instead of releasing for new version of Scala… they rewrite codebase to Java, and said “you can use us from Scala but we don’t want to bother dealing with your issues”). If a library was already on Scala Next, because it needed the new features, it would be able to stabilize on new LTS. If library works perfectly well on old LTS (no maintanance burden related to compiler bugs, or tricks how to support new features while compiling core in old compiler), it’s purely aesthetic move.
1 Like
Maybe I’m nitpicking language, but in the Scala 3 case, I wouldn’t call it “mass extinction”, because old libraries don’t stop working. You just have to upgrade your Scala first if you want newer libraries.
I used that sneaky little word “just”, there. But moving to a new Scala 3 version isn’t anywhere near as scary as moving to a new Scala 2.x version was in the old days, exactly because you can do it without upgrading any of your libraries.
I assume you understand this already; I’m just saying, for the forum audience, that the wording above seems unnecessarily alarming to me.
1 Like