Skip to content

Use "java.home" to launch the BSP server even when using the sbt script #8300 - #8301

Open
unkarjedy wants to merge 3 commits into
sbt:developfrom
unkarjedy:1.11.x
Open

unkarjedy wants to merge 3 commits into
sbt:developfrom
unkarjedy:1.11.x

Conversation

@unkarjedy

@unkarjedy unkarjedy commented Sep 25, 2025

Copy link
Copy Markdown
Contributor

Fixes #8300

image

dependabot Bot and others added 3 commits September 13, 2025 21:01
Bumps [actions/setup-python](https://github.com/actions/setup-python) from 5 to 6.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](actions/setup-python@v5...v6)

---
updated-dependencies:
- dependency-name: actions/setup-python
  dependency-version: '6'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
…/actions/setup-python-6

[1.x] Bump actions/setup-python from 5 to 6
sbt#8300

It's similar to another commit for the cause when sbt-launch is used to start the bsp server:
> Use java home to launch BSP server
> 964c1cb Samuel CLARENC <samuel.clarenc@teads.tv> on 01/07/2021 at 13:48
  committed on 26/07/2021
List(arguments.sbtScript) ++ arguments.sbtArguments ++
// From sbt/sbt.sh/sbt.bat:
// --java-home <path> alternate JAVA_HOME
val javaHomeArgs = javaHomeOpt.toSeq.flatMap(javaHome => Seq("--java-home", javaHome))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that java.home system properties, even though it is named as such, isn't the same as JAVA_HOME.
See https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html

"java.home": Installation directory for Java Runtime Environment (JRE)

This means that java would be on the path, but if I recall correctly, javac will not be on the path, which could break Java compilation.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch.
It slipped my attention, partially because I already saw the approved change that included the "java.home".
Though those two branches are different...

While I was looking into some issues related to BSP and IntelliJ I noticed that current state of BSP lacks a more transparent JDK management and depends on global state too much.

It seems there is no way to explicitly specify which JDK should be used in the .bsp/sbt.json file.
If you pass -bsp you can't pass the --java-home parameter after it.
The sbt.internal.client.NetworkClient.parseArgs will fail to parse it as sbtArgument passed to the script.
Sbt script expects --java-home <path> (separated with a space) and NetworkClient.parseArgs doesn't work with the space and treats the <path> as a sbt command.
We could try fixing this in a more general case (support for space " ") or just try to add 1 dedicated parameter for JDK path (~--java-home in sbt script, ~ JAVA_HOME env var).

If there was a way to specify the JDK more trasnparently, then we would also need to patch the
sbt.internal.bsp.BuildServerConnection.writeConnectionFile.

@eed3si9n WDYT? Does it make sense?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are passing in the script location via system properties, like

"-Dsbt.script=/Users/xxx/.sdkman/candidates/sbt/current/bin/sbt"

so we could pass in JAVA_HOME as -Dsbt.java.home and use that when present.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SBT ignores JDK used in launcher in --bsp mode

2 participants