**Problem**
sbt bspConfig writes the absolute path of the current Java binary into .bsp/sbt.json. When the user switches Java versions (via sdkman, cs java, etc.) or removes that JDK, the IDE fails to start the sbt BSP server because the hardcoded path is stale or gone.
**Solution**
When an sbt launcher script is available (via `sbt.script` system property or PATH lookup), generate:
"argv": ["/path/to/sbt", "bsp"]
**Problem**
Scripts with scalaVersion 3.x in /*** */ and a shebang fail: -Xscript is
ignored by Scala 3, and the shebang line causes "Expected a toplevel
definition".
**Solution**
- Strip shebang when copying the script so the compiler never sees it.
- For Scala 3 only: do not add -Xscript; generate Main.scala wrapping the
script body in object Main { def main(...) = { ... } }; use it as the
single source and set run/mainClass to Main.
- For Scala 2: keep existing behavior (shebang stripped, -Xscript + script
base name).
- Use Def.uncached and ScalaArtifacts.isScala3(scalaVersion.value) so
embedded scalaVersion from /*** */ is respected.
**Problem**
When sbtn (native thin client) can't find a running sbt server, it prompts
to start one. There was no way to opt out of server auto-start from the
client side, which is needed for CI environments and scripting (sbt/sbt#7079).
**Solution**
Reuse the existing sbt.server.autostart system property in NetworkClient
to control whether sbtn should attempt to start a server. When no server is
running and sbt.server.autostart=false, sbtn exits with an error instead
of prompting.
Support setting this property via:
- sbtn --no-server compile (sets sbt.server.autostart=false)
- sbtn --autostart=false compile (new flag following sbt conventions)
- sbtn -Dsbt.server.autostart=false compile (direct system property)
- sbt --autostart=false compile (bash runner and sbtw)
This follows sbt's naming conventions for properties/options: positive
property names with =false opt-out (like --color=false, --supershell=false).
Fixessbt/sbt#7079
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Avoid launching sbt just to render --version by reading sbt.version directly from project/build.properties in the shell script, batch script, and sbtw wrapper. Tighten launcher integration assertions to verify version output no longer depends on the sbtVersion command output.
**Problem**
Running sbt 2.x with JDK 8 produces a confusing "server was not
detected" error because the JDK version check only required JDK 8+
and only ran in the non-native-client path.
**Solution**
Move java_version detection before the native client decision and add
checkJava17ForSbt2 that requires JDK 17+ when sbt major version >= 2.
Fixes#8813
* [2.x] fix: Fail early when sbt 2.x is run with JDK < 17 (sbtw)
Move JDK version check before native client decision in sbtw and
require JDK 17+ when build.properties declares sbt 2.x.
* [2.x] fix: Fail early when sbt 2.x is run with JDK < 17 (sbt.bat)
Move checkjava before native client decision in sbt.bat and require
JDK 17+ when build.properties declares sbt 2.x.
* [2.x] test: Add minimumJdkVersion helper and unit tests for sbtw
Extract JDK version check logic into Runner.minimumJdkVersion for
testability. Add RunnerSpec with tests for sbt 1.x, 2.x, and 3.x
version detection.
* [2.x] test: Bump fake java to JDK 17 for integration tests
The fake java script used by launcher integration tests reported
JDK 8. Since sbt 2.x now requires JDK 17+, the citest2 (sbt 2.x)
integration tests would fail with the new JDK version check.
* Simulate JDK 9+ rt.jar handling in fake java script
Instead of silently ignoring --rt-ext-dir (which causes sbt.bat
to mkdir on an empty string), properly simulate JDK 9+ behavior
by creating a temp directory with java9-rt-ext- prefix and a
dummy rt.jar inside it.
BitToby
kenji yoshida
bitloi
Dream