After setup of Java 17, subprocess still runs with 11

[headius]

Description:

The JRuby build installs specific versions of JDK to build and run tests with, but it seems like any JRuby subcommand run by the build is picking up a Java 11 install regardless of the setup-java JDK version.

This recently came up here: https://github.com/jruby/jruby/pull/8378/checks#step:2:4079

The JRuby build apparently ran with Java 17 (creating org/jruby/Main with bytecode version 61), but when a later part of the build shells out to run JRuby it appears to run with Java 11 (failing to load JRuby because it supports up to bytecode version 55).

I do not see how it could be picking up Java 11 in the subprocess.

Task version:

"v4"

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:

See failed build here: https://github.com/jruby/jruby/pull/8378/checks#step:2:4079

Expected behavior:

All Java-related commands should run with the setup-java JDK version (17 in this case).

Actual behavior:

It seems that some commands (subprocess run from maven, for example) is picking up Java 11 somewhere.

[priyagupta108]

Hi @headius 👋,
Thank you for your report. We will investigate the issue and get back to you as soon as we have updates.

[headius]

I believe I have worked around it temporarily by explicitly removing the preinstalled JDK packages, installing the version I need, and proceeding from there. I have no theories as to why it picks up one of the preinstalled JDKs in a subprocess of Maven.

[priyagupta108]

Hi @headius,
It looks like the Action worked correctly. The logs indicate that the JAVA_HOME is correctly set to Java 17, and I observe the same error occurring when running with Java 21.
I attempted to reproduce the issue on a simple project, and everything functioned as expected. Therefore, I believe this might be an issue specific to your setup.
Could you please try to reproduce the issue outside of your repository on a different simple project?

[headius]

@priyagupta108 A simpler project probably would not show the same effect, but it might be possible to simulate enough of it by having Maven shell out to a subprocess and see if it picks the wrong JDK.

Notice that in my subsequent commits I had to remove all the "wrong" JDKs that were installed by default or they would be selected; it is almost as if something in either Maven or the toolchain around it is defaulting to /usr/bin/java which probably was still set up as the java alternative for Ubuntu. This might happen if, for example, the subprocess env loses the custom PATH set up by setup-java (I assume it sets PATH to the requested JDK?).

Given the default set of JDKs, perhaps there's more that setup-ruby could do to make the JDK it installs actually be registered as the default JDK for the system?