Move Scala 3 to 3.9.0 LTS

[julien-truffaut]

Moves the Scala 3 build from 3.3.8 to 3.9.0 LTS (released 2026-09-03).

Warning

This raises the JDK baseline for Scala 3 artifacts from 11 to 17. That is forced by the compiler, not a preference — see below.

Why the JDK baseline has to move

3.9.0 will not emit Java 11 bytecode. From ScalaSettingsProperties.scala at tag 3.9.0:

private val minTargetVersion = 17
private val maxTargetVersion = 26
private val minReleaseVersion = 17

Against 3.3.8, where the minimum came from the full classfileVersionMap and went down to Java 8. Keeping -release:11 fails the build outright:

[error] 11 is not a valid choice for -java-output-version

The same limit rules out the temurin@11 CI leg: supported release versions are computed as (minReleaseVersion to min(jdkVersion, maxTargetVersion)), which on JDK 11 is (17 to 11) — an empty range. So the matrix moves to temurin@17 and the workflows are regenerated.

Scala 2.13 is unaffected and keeps -release:8.

The release flag now follows the binary version, on every platform

monocleJvmSettings keyed its flags off a string prefix, and the JS and Native settings added -release:8 unconditionally:

lazy val monocleJvmSettings = ... ++ Seq(scalacOptions ++= {
  if (scalaVersion.value.startsWith("3.3.")) Seq("-Yfuture-lazy-vals", "-release:11")
  else if (scalaBinaryVersion.value == "3")  Nil        // 3.9.0 would land here
  else                                        Seq(defaultReleaseOption)
})
lazy val monocleJsSettings     = ... ++ Seq(scalacOptions += defaultReleaseOption)  // "-release:8"
lazy val monocleNativeSettings = ... ++ Seq(scalacOptions += defaultReleaseOption)  // "-release:8"

Two separate problems there. On the JVM, bumping the version alone would have stopped matching the first branch and silently dropped the release flag — no error, just a changed bytecode target in published artifacts. On JS and Native, -release:8 is rejected outright under 3.9 (8 is not a valid choice for -java-output-version); it only ever worked because Scala 3 was pinned at 3.3.8.

All three now route through one setting:

lazy val releaseOption = Def.setting {
  if (scalaBinaryVersion.value == "3") scala3ReleaseOption else defaultReleaseOption
}

-Yfuture-lazy-vals goes too: the setting exists in 3.3.8 but was removed in 3.9.0, so passing it would fail the build. Its behaviour is the default now.

scalaNextVersion 3.8.4 → 3.10.0-RC1

scalaNextTest depends on core, now built by 3.9.0 and emitting TASTy 28.9. The 3.8.4 compiler reads at most 28.8:

[error] Forward incompatible TASTy file has version 28.9, produced by Scala 3.9.0,
[error]   expected stable TASTy from 28.0 to 28.8.

The project exists to exercise the line ahead of what we publish, so it has to move past 3.9.0 rather than trail it. Note this puts an RC in CI — deliberate, and the reason scalaNextTest exists, but worth flagging.

Verification

Run locally on 3.9.0:

• rootJVM/test — 2006 tests, 0 failures
• coreJVM / coreJS / coreNative / macrosJS / macrosNative compile
• scalaNextTestJVM/test on 3.10.0-RC1 against 3.9.0-built core — 36 tests, 0 failures
• mimaReportBinaryIssues, scalafmtSbtCheck, githubWorkflowCheck all clean
• Re-ran the cross-build on 2.13.18 to confirm no regression; resolved flags verified as -release:17 on Scala 3 and -release:8 on 2.13

As a side effect the regenerated workflow clears the Using JDK 11 with Scala Native ... is deprecated and Using sbt-scalajs on JDK 11 is deprecated warnings that were showing up in release logs — both wanted JDK 17 already.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QRbVCYWp3bquNaXPYW12JY

[cquiroz]

LGTM