Bug: JAVA_HOME not defined for GUI apps on Linux (Gnome)
sonicdebris opened this issue · 3 comments
Not sure this is an issue with sdkman and if this is the right place to post it, but I thought it would be of interest.
Bug report
The JAVA_HOME as set by sdkman is not available to GUI applications on Linux with Gnome Shell.
To reproduce
- Install Android Studio (using Jetbrains Toolbox)
- In Settings -> Build, Execution, Deployment -> Gradle, click on the Gradle JDK selection box
- Look at the value for JAVA_HOME -> it doesn't match the one set by sdkman
Workaround
- On X11, export the variable in
.profile - On Wailand, define the variable in
.config/environment.d/envvars.conf
More context
https://issuetracker.google.com/issues/162313337
System info
Ubuntu (Pop_OS) and Arch (Manjaro), with gnome shell, both Wayland and X11
Hi @sonicdebris ,
This is because SDKMAN is primarily a CLI tool (so it does not set environment variables for your current X or Wayland login session). When a new shell is opened, the JAVA_HOME and HOME environment variables are evaluated dynamically for that shell, and can be updated locally. This allows us to run multiple shells with different XXX_HOME variables for any candidate. For instance:
$ sdk use java 17.0.10-tem
$ echo $JAVA_HOME
now open a new shell and type:
$ sdk use java 17.0.9-tem
$ echo $JAVA_HOME
Each shell has a different JAVA_HOME and HOME variable.
Hope it makes more sense now!
Yes it makes sense. It would still be nice if at least sdk default could influence the "UI shell" as well, but I guess that with the workarounds I am using already it's not such a big deal.
Unfortunately we don't have control of anything outside of the shell since it's purely a bash process.
However, my suggestion would be to use the current symlink under the java candidate to set up such a system wide alias as that tracks the default. Alternatively you can use the sdk home command to infer this location.