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?

[priyagupta108]

@headius 👋 , Thank you for the detailed explanation.
I attempted to reproduce the issue by setting up a similar environment, but I was unable to replicate the problem.
The setup-java action sets the PATH to the requested JDK version but does not switch versions through update-alternatives. If the specified Java version is available in the hosted toolcache directory, the action will add Java's bin directory to the PATH and create the JAVA_HOME environment variable. If the specified version is not available, the action will download it to the hosted toolcache directory, add it to the PATH, and create the JAVA_HOME environment variable. In most cases, setting the JAVA_HOME environment variable is sufficient to specify which Java version should be used by tools and scripts.
However, some tools and subprocesses might not respect the JAVA_HOME environment variable and instead rely on the system's default java and javac.
As a workaround, you can update the system's default Java version using the update-alternatives command. This ensures that the correct Java version is used even if JAVA_HOME is not respected. Here is a sample configuration:

- name: Set alternatives for java and javac
  run: |
    sudo update-alternatives --set java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java
    sudo update-alternatives --set javac /usr/lib/jvm/temurin-17-jdk-amd64/bin/javac

[priyagupta108]

Hello, @headius ! Just checking in to see if there are any updates on your end regarding this issue? Thank you :)

[headius]

Hey, sorry, I think we can close this as "invalid". We noticed the same issue running some local builds that don't use setup-java at all. There appears to be some glitch in how Maven combined with JRuby launches subprocesses that's losing the environment and falling back on defaults.

I would encourage you to do more to make sure setup-java also configures the default Linux Java alternative, but the issues we saw do not appear to be your fault.

[priyagupta108]

Thank you for providing the update and suggestion regarding the configuration of the default Linux Java alternative.
Since the issue seems to be related to a glitch with Maven and JRuby rather than setup-java action, I am closing this issue. Please feel free to reach out to us in case of any concerns.