Host system's Java environment not available in Steam Linux Runtime

[adina-the-nerd]

Your system information

• Steam client version (build number or date): multilib/steam 1.0.0.81-2
• Distribution (e.g. Ubuntu): EndveorOS on Zen (x11 & Wayland separately)
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes
• Steam Logs: steam-logs.tar.gz
• GPU: AMD

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist

Steps for reproducing this issue:

1. Open Steam
2. Open Godot
3. Make a mobile project
4. Make a 2D scene
5. Set any installed Java directory for Android (Installed from a system repository)
6. Set an Android SDK directory
7. Attempt to export as an APK
8. Get the error "-Invalid Java SDK path in Editor Settings.Missing 'bin' directory!"

Steps for temporarily fixing the issue:

1. Run the command "steam -compat-force-slr off" to lunch Steam
2. Try the previous steps

Recommended possible fixes:

1. Add the "Native Linux Runtime" option to the "Steam Play compatibility tool" list as a non-default choice
2. Add The "-compat-force-slr" command to Lanch Options
3. Add the "Native Linux Runtime" option to the "Steam Play compatibility tool" list as a default choice for non-game software

[smcv]

The Steam Runtime does not include a Java runtime environment or development kit (JRE or JDK). If the Godot engine is relying for some of its optional or required functionality on the host system having a JRE or JDK with a particular layout installed separately, that's never been something that has been a guarantee.

A future Steam Client beta is likely to mitigate this by adding a new option, Properties → Compatibility → Force the use of... → Legacy Runtime, which will return to running the app/game in the non-container LD_LIBRARY_PATH-based environment that Steam has traditionally used. App/game developers will likely also be able to select the legacy (non-container) runtime as the default for individual titles.

The default for native Linux titles with no specific configuration will continue to be the Steam Linux Runtime 1.0 container (unless the -compat-force-slr off option is used, in which case the default is the legacy runtime).

The Steam Linux Runtime is going to be more stable over time than the legacy runtime, in the sense that if a title works in SLR 1.0 today, then that title is more likely to continue working in SLR 1.0 in future than anything we could achieve with the legacy LD_LIBRARY_PATH-based runtime.

The legacy runtime has the same behaviour that was the default on desktop before November 2024, so it's very easy for titles in this runtime to pick up undocumented dependencies on implementation details of the host system (such as the presence of a JRE whose layout meets the title's assumptions), either intentionally or accidentally. If a title works in the legacy runtime today, it cannot be assumed to continue working forever, because changes in the underlying system could break the title's assumptions at any time (but that was always true, and hasn't changed).

Add the "Native Linux Runtime" option to the "Steam Play compatibility tool" list as a non-default choice

We intentionally avoid saying "native" to mean "use (more of) the host system's libraries" or "don't run in a a container", because it's an ambiguous term: some people use it to mean one of those two things, but more often it means a Linux/glibc/ELF executable that can be run directly (as opposed to a Windows/PE executable that needs to be run via Wine/Proton).

Linux titles distributed through Steam are expected to use the cross-distro compatibility mechanisms that Steam provides, and Steam is unlikely to add a compatibility tool option that genuinely does not use any cross-distro compatibility layer and uses the host system's libraries as-is, because there is so little that an app/game can rely on about the host system's libraries. If what you want is a standalone executable whose developer has taken full responsibility for figuring out portability, with full access to all implementation details of the host OS, the recommendation is to download it separately and add it to Steam as a non-Steam app/game.

[smcv]

Java accessibility

When I saw this title, I thought for a moment that you meant this sort of accessibility. Perhaps a better title for this issue would be "host system's Java environment not available in Steam Linux Runtime".

[adina-the-nerd]

Perhaps a better title for this issue would be "host system's Java environment not available in Steam Linux Runtime".

Agreed

[adina-the-nerd]

If the Godot engine is relying for some of its optional or required functionality on the host system having a JRE or JDK with a particular layout installed separately, that's never been something that has been a guarantee.

Applications will end up needing dependencies outside of Steam Play. Some sort of solution for required dependencies will be needed for proper feature completion in some use cases Java or not.

As for saying it's never been a guarantee, I think it has been implied functionality by allowing Linux native build to require things like Java that aren't supplied by Steam Play as per the "Valve Corporation - Steam Distribution Agreement, section 8.2 (B)" While I don't believe this means Valve has to supply all required dependencies; This does reasonably implies system Library/dependency access.

This also isn't just Godot this is also the Linux native build of "Rise To Ruins", and likely more.

A future Steam Client beta is likely to mitigate this by adding a new option, Properties → Compatibility → Force the use of... → Legacy Runtime, which will return to running the app/game in the non-container LD_LIBRARY_PATH-based environment that Steam has traditionally used. App/game developers will likely also be able to select the legacy (non-container) runtime as the default for individual titles.

This Sounds like a perfectly fine fix! Though I'm not sure if the name properly describes its function. Maybe something like “System Linux Runtime", “Uncontained Linux Runtime”, “Opened Linux Runtime”, “System Supplied Linux Runtime”, "Host's Linux Runtime" or “Unstable Linux Runtime” as I think people would likely try to use "Legacy Runtime" on older applications instead of for overall usage with applications that this issue affects.

The default for native Linux titles with no specific configuration will continue to be the Steam Linux Runtime 1.0 container (unless the -compat-force-slr off option is used, in which case the default is the legacy runtime).
Agreed.

The Steam Linux Runtime is going to be more stable over time than the legacy runtime, in the sense that if a title works in SLR 1.0 today, then that title is more likely to continue working in SLR 1.0 in future than anything we could achieve with the legacy LD_LIBRARY_PATH-based runtime.

This is true, but not a reason to get rid of non-container options nor is this a reason to make them inaccessible.

The legacy runtime has the same behaviour that was the default on desktop before November 2024, so it's very easy for titles in this runtime to pick up undocumented dependencies on implementation details of the host system (such as the presence of a JRE whose layout meets the title's assumptions), either intentionally or accidentally. If a title works in the legacy runtime today, it cannot be assumed to continue working forever, because changes in the underlying system could break the title's assumptions at any time (but that was always true, and hasn't changed).

This makes sense, but still isn't a reason to get rid of non-container options nor is this a reason to make them inaccessible.

We intentionally avoid saying "native" to mean "use (more of) the host system's libraries" or "don't run in a a container", because it's an ambiguous term: some people use it to mean one of those two things, but more often it means a Linux/glibc/ELF executable that can be run directly (as opposed to a Windows/PE executable that needs to be run via Wine/Proton).

That's fair, but I still think "Legacy Runtime" isn't a great name for the reasons I listed above.

Linux titles distributed through Steam are expected to use the cross-distro compatibility mechanisms that Steam provides, and Steam is unlikely to add a compatibility tool option that genuinely does not use any cross-distro compatibility layer and uses the host system's libraries as-is, because there is so little that an app/game can rely on about the host system's libraries. If what you want is a standalone executable whose developer has taken full responsibility for figuring out portability, with full access to all implementation details of the host OS, the recommendation is to download it separately and add it to Steam as a non-Steam app/game.

“Linux titles distributed through Steam are expected to use the cross-distro compatibility mechanisms that Steam provides”. This is in no way listed by the "Valve Corporation - Steam Distribution Agreement" nor was it implied until this month. This is not a reasonably communicated expectation set by Valve or Steam.

"If what you want is a standalone executable whose developer has taken full responsibility for figuring out portability, with full access to all implementation details of the host OS, the recommendation is to download it separately and add it to Steam as a Non-Steam game" If a piece of software is listed on Steam the expectation should be that if Valve breaks anything on Steam it sould be fixable with at most a few setting changes. IE: Changing what Steam Play compatibility tool you're using. A good thing to compare this to is breaking userspace; It souldn’t happen.

“There is so little that an app/game can rely on about the host system's libraries”. On Windows, Valve is fine with letting games require dependencies that need to be installed manually. So it shouldn't be a restricted or inaccessible action on Linux.