After setup of Java 17, subprocess still runs with 11

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.

@headius

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

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.

Remove default Java installs so they are not used

@headius

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?

@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?

@headius

@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

@headius

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

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.

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.

Navigation Menu

Repository navigation

After setup of Java 17, subprocess still runs with 11 #701

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

After setup of Java 17, subprocess still runs with 11 #701

Description

Activity

v-priyagupta108 commented on Oct 23, 2024

headius commented on Oct 30, 2024

v-priyagupta108 commented on Nov 5, 2024

headius commented on Nov 5, 2024

v-priyagupta108 commented on Nov 11, 2024

v-priyagupta108 commented on Nov 25, 2024

headius commented on Nov 25, 2024

v-priyagupta108 commented on Nov 27, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions