Fixes#7469
When running 'sbt bspConfig', the generated .bsp/sbt.json now includes
JVM options from the SBT_OPTS environment variable. This ensures that
options like -Dsbt.boot.directory are propagated to the BSP server.
The parseSbtOpts method extracts -D, -X, and -J prefixed options from
SBT_OPTS and includes them in the BSP connection argv.
** Problem **
The sbtn (sbt thin client) native image on Linux currently depends on glibc because ipcsocket uses JNI for Unix domain sockets. When building with musl for static linking, the JNI library fails to load since musl doesn't support `dlopen`.
** Solution **
Instead of upgrading to ipcsocket 2.x (which isn't ready for production), I created a `UnixDomainSocketFactory` that detects JDK 17+ at runtime and uses the native `java.net.UnixDomainSocketAddress` API directly via reflection. This completely bypasses JNI on modern JDKs.
For older JDKs (8 and 11), the factory falls back to ipcsocket 1.6.3, which is stable and well-tested.
** How It Works **
The factory checks at startup whether `java.net.UnixDomainSocketAddress` is available:
- **JDK 17+**: Uses native NIO Unix domain sockets (no JNI, no native libraries)
- **JDK 8/11**: Falls back to ipcsocket's JNI-based implementation
This approach:
- Enables musl static linking on JDK 17+ without any native dependencies
- Maintains full backward compatibility with older JDKs
- Keeps the stable ipcsocket 1.6.3 instead of the unstable 2.x
Set window title to 'sbt <command>: <org> % <name> % <version>' when
running sbt run, runMain, bgRun, or bgRunMain.
For server-side runs, window title is set directly. For client-side runs (sbtn), window title is passed via RunInfo protocol
and set by NetworkClient.
Fixes#7586
**Problem**
There are a few places where javaHome or java path is set,
using java.home system property. The problem is that it points to JRE,
not JDK, so it would break on Java compilation etc.
**Solution**
If the path ends with jre, go up one directory.
**Problem**
`run` task blocks the server, but during the run the server is just
waiting for the built program to finish.
**Solution**
This implements client-side run where the server creates a sandbox
environment, and sends the information to the client,
and the client forks a new JVM to perform the run.
**Problem**
There are a few places where javaHome or java path is set,
using java.home system property. The problem is that it points to JRE,
not JDK, so it would break on Java compilation etc.
**Solution**
If the path ends with jre, go up one directory.
I believe this was just an oversight that it's not marked as true since
sbt can handle `debugSession/start`. This change just ensures that
during the initialization process sbt says it's a `debugProvider` for
the same languages as `runProvider` and `testProvider`. It also
correctly marks the build targets as `canDebug`, unless they are sbt
targets.
Before, the BSP config .bsp/sbt.json generated by `sbt bspConfig`
contained a command line which required the sbt binary in the PATH.
This fix changes the nature of the -Dsbt.script option. It was
an argument of the main class xsbt.boot.Boot, it's now a system
property and thus it's used to launch the sbt server.
Fixes https://github.com/sbt/sbt/issues/6760
Migrates TreeView.scala to use Contraband from scala.util.parsing.json,
because this is now deprecated.
The TreeView logic is used in the dependencyBrowseTree task.
In order to start the sbt server we must use the sbt script because
it is the only way to load the .sbtopts and the .jvmopts file properly.
To do so the sbt script can pass a -Dsbt.script prop to the java server.
It is used in the NetworkClient to start the server, and it is replicated
in the BuildServerConnection file (.bsp/sbt.json).
eugene yokota
MkDev11
xuwei-k
Friendseeker
Adrien Piquerez
Julien Richard-Foy
Chris Kipp
Vadim Chelyshov
Krzysztof Pado
Kamil Podsiadlo
gontard
David Francoeur
Amina Adewusi
Igal Tabachnik
Samuel CLARENC
Samuel CLARENC