Skip to content

Switch JAVA_HOME to 21 for JRuby #721

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 12 commits into from
Mar 12, 2025
Merged

Conversation

headius
Copy link
Contributor

@headius headius commented Mar 11, 2025

JRuby 10 requires Java 21. Since the previous default was 17 and all JRuby releases should work fine on 21, we do this for all JRuby installs.

Implements #718

@headius headius force-pushed the java_21_for_jruby branch from 22e5251 to 061b308 Compare March 11, 2025 20:53
@headius
Copy link
Contributor Author

headius commented Mar 11, 2025

@eregon This is a quick attempt to implement what I need.

I am not sure how to detect if the user has already reassigned JAVA_HOME, either manually or by setup-java. It may not be possible.

I am trusting that os.arch() returns x64 or arm64 as expected elsewhere.

Not sure how to make this more robust.

JRuby 10 requires Java 21. Since the previous default was 17 and
all JRuby releases should work fine on 21, we do this for all
JRuby installs.

Implements ruby#718
@headius headius force-pushed the java_21_for_jruby branch from 061b308 to 4158eb5 Compare March 11, 2025 20:57
@headius
Copy link
Contributor Author

headius commented Mar 11, 2025

FWIW GitHub may soon bump the default Java to 21, at which point we won't need this anymore.

@eregon
Copy link
Member

eregon commented Mar 11, 2025

FWIW GitHub may soon bump the default Java to 21, at which point we won't need this anymore.

Interesting, any issue I can follow about that?

@headius
Copy link
Contributor Author

headius commented Mar 11, 2025

any issue I can follow about that

No, I just assume they eventually move the default version up. Obviously they moved it up to 17 at some point.

The JAVA_HOME_* variables use 'arm64' on ARM.
@headius headius force-pushed the java_21_for_jruby branch from 5d3234e to ef40e17 Compare March 11, 2025 21:23
@headius
Copy link
Contributor Author

headius commented Mar 11, 2025

Latest run appears to be green and handles arch properly on macos. Ruby version shows JRuby is running with 21.

@headius
Copy link
Contributor Author

headius commented Mar 11, 2025

@eregon Let me know if there's additional work needed here. Whenever this goes live, we can start unpinning jruby-head builds from 9.4.

@eregon
Copy link
Member

eregon commented Mar 11, 2025

I am not sure how to detect if the user has already reassigned JAVA_HOME, either manually or by setup-java. It may not be possible.

One idea given https://github.com/eregon/actions-shell/actions/runs/13798182243/job/38594765309#step:4:5

JAVA_HOME
/usr/lib/jvm/temurin-11-jdk-amd64
JAVA_HOME_8_X64
/usr/lib/jvm/temurin-8-jdk-amd64
JAVA_HOME_11_X64
/usr/lib/jvm/temurin-11-jdk-amd64
JAVA_HOME_21_X64
/usr/lib/jvm/temurin-21-jdk-amd64
JAVA_HOME_17_X64
/usr/lib/jvm/temurin-17-jdk-amd64

would be to only set it if JAVA_HOME_21_X64 exists (e.g. might not exist on self-hosted runners) and JAVA_HOME is too old.
That way setup-ruby only overrides JAVA_HOME if strictly necessary.

You could get the Java version from $JAVA_HOME/bin/java -version, from reading the release file (might not always be available though), or from finding out which JAVA_HOME_$V_X64 env vars corresponds to JAVA_HOME and then Java version = $V.
That last one seems overkill, java -version seems fast enough, about 27ms when run locally.

@headius
Copy link
Contributor Author

headius commented Mar 11, 2025

Detecting the existing JAVA_HOME version is problematic; we'll have to parse the output of either -version or -XinternalVersion or the release file (not available on Java 8) and determine if the major version is > 21. Perhaps the better option would be to simply run jruby -v and if it fails we know we need to force JAVA_HOME or error out if there's no 21 env available.

@eregon
Copy link
Member

eregon commented Mar 11, 2025

Could you add the check with $JAVA_HOME/bin/java -version so it's only set if the default Java is too old?
That seems a lot safer, e.g. wouldn't override a workflow setting JAVA_HOME to 25 or downgrade when e.g. some runner (self-hosted or not) has a default more recent than 21.

@headius
Copy link
Contributor Author

headius commented Mar 11, 2025

Could you add the check with $JAVA_HOME/bin/java -version

I believe a more robust option is to run JRuby and only update JAVA_HOME if it fails.

@eregon
Copy link
Member

eregon commented Mar 11, 2025

Is parsing the output of -version so tricky? (I don't know)
e.g.

$ java -version
openjdk version "21.0.6" 2025-01-21
OpenJDK Runtime Environment (Red_Hat-21.0.6.0.7-1) (build 21.0.6+7)
OpenJDK 64-Bit Server VM (Red_Hat-21.0.6.0.7-1) (build 21.0.6+7, mixed mode, sharing)

We could match the first line there, e.g. by matching the first number (/\d+/).

Using jruby -v there would make the logic a lot more complex and brittle so I don't think that's a good way.

@eregon
Copy link
Member

eregon commented Mar 11, 2025

I believe a more robust option is to run JRuby and only update JAVA_HOME if it fails.

Feel free to try it, e.g. in another PR.
I suspect it will be rather messy in practice.

@headius
Copy link
Contributor Author

headius commented Mar 11, 2025

We could match the first line there, e.g. by matching the first number (/\d+/).

Using jruby -v there would make the logic a lot more complex and brittle so I don't think that's a good way.

Parsing version output will be subject to any changes that might happen in the future, and won't parse right if it's not OpenJDK (OpenJ9 has a different -version output for example).

Simply attempting to run jruby -v and checking for success is trivially easy in comparison.

@headius headius force-pushed the java_21_for_jruby branch from 29d6dd3 to 7ffdbb4 Compare March 11, 2025 22:11
@headius
Copy link
Contributor Author

headius commented Mar 11, 2025

Not sure why the exec call is producing that error. I am not familiar with how async/await or this exec module work and tried to mimic the other call I saw.

@headius
Copy link
Contributor Author

headius commented Mar 11, 2025

The new logic is working (update only if ruby --version fails), but of course all JRuby releases it sees are 9.4 and start up fine with Java 17. However the rest of the logic is not changed from what it did before, so it should still be working. I'm not sure how to test both scenarios.

Copy link
Member

@eregon eregon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, just a few more tweaks and it should be ready to be merged.

@eregon
Copy link
Member

eregon commented Mar 12, 2025

However the rest of the logic is not changed from what it did before, so it should still be working. I'm not sure how to test both scenarios.

Yes, I think there is no way to know until we get a JRuby 10 build, i.e. when we switch jruby-dev-builder to use master.
At that point we can trigger a workflow there manually and run the CI here (e.g. on a branch/draft PR) and see if everything is fine, if it's not we can revert the change in jruby-dev-builder & delete the last release there.

@headius headius force-pushed the java_21_for_jruby branch from d69712b to dad12fe Compare March 12, 2025 17:19
@headius
Copy link
Contributor Author

headius commented Mar 12, 2025

Changes from latest review are in and green.

common.js Outdated
@@ -6,6 +6,8 @@ const stream = require('stream')
const crypto = require('crypto')
const core = require('@actions/core')
const tc = require('@actions/tool-cache')
const exec = require('@actions/exec')
const common = require('./common')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a require of this file, it seems safer to avoid it, as I guess it might cause some weird stuff.
I'll fix it.

@eregon
Copy link
Member

eregon commented Mar 12, 2025

There is some weird output e.g. in https://github.com/ruby/setup-ruby/actions/runs/13817559138/job/38654730800?pr=721#step:3:18

Modifying JAVA_HOME for JRuby
  attempting to run with existing JAVA_HOME
  > Print Ruby version
  /home/runner/.rubies/jruby-9.4.12.0/bin/ruby --version
  /home/runner/.rubies/jruby-9.4.12.0/bin/ruby --version
  jruby 9.4.12.0 (3.1.4) 2025-02-11 f4ab75096a OpenJDK 64-Bit Server VM 11.0.26+4 on 11.0.26+4 +jit [x86_64-linux]
  jruby 9.4.12.0 (3.1.4) 2025-02-11 f4ab75096a OpenJDK 64-Bit Server VM 11.0.26+4 on 11.0.26+4 +jit [x86_64-linux]
  JRuby successfully starts, using existing JAVA_HOME
  Took   2.78 seconds
Took   2.78 seconds

i.e. as if Print Ruby version was nested in Modifying JAVA_HOME for JRuby, but it shouldn't be.

The raw log gives:

2025-03-12T17:20:13.3657278Z ##[group]Extracting  Ruby
2025-03-12T17:20:13.3699863Z [command]/usr/bin/tar -xz -C /home/runner/.rubies -f /home/runner/work/_temp/0f9a3f7e-948e-43d0-b0dc-b3392b0fe27d
2025-03-12T17:20:13.6921000Z Took   0.33 seconds
2025-03-12T17:20:13.6924400Z ##[endgroup]
2025-03-12T17:20:13.6927040Z ##[group]Modifying JAVA_HOME for JRuby
2025-03-12T17:20:13.6929228Z attempting to run with existing JAVA_HOME
2025-03-12T17:20:13.6931648Z > Print Ruby version
2025-03-12T17:20:13.6947158Z [command]/home/runner/.rubies/jruby-9.4.12.0/bin/ruby --version
2025-03-12T17:20:13.6971579Z [command]/home/runner/.rubies/jruby-9.4.12.0/bin/ruby --version
2025-03-12T17:20:16.4676830Z jruby 9.4.12.0 (3.1.4) 2025-02-11 f4ab75096a OpenJDK 64-Bit Server VM 11.0.26+4 on 11.0.26+4 +jit [x86_64-linux]
2025-03-12T17:20:16.4678621Z jruby 9.4.12.0 (3.1.4) 2025-02-11 f4ab75096a OpenJDK 64-Bit Server VM 11.0.26+4 on 11.0.26+4 +jit [x86_64-linux]
2025-03-12T17:20:16.4771213Z JRuby successfully starts, using existing JAVA_HOME
2025-03-12T17:20:16.4771975Z Took   2.78 seconds
2025-03-12T17:20:16.4773023Z ##[endgroup]
2025-03-12T17:20:16.4773566Z Took   2.78 seconds
2025-03-12T17:20:16.4775891Z ##[group]Installing Bundler

So these two steps seem to interleave somehow, maybe a missing await then?

@eregon eregon force-pushed the java_21_for_jruby branch from 9877756 to 9b80b4d Compare March 12, 2025 20:05
@eregon
Copy link
Member

eregon commented Mar 12, 2025

FWIW the first ruby --version can take a while on JRuby:
0.74s https://github.com/ruby/setup-ruby/actions/runs/13820508511/job/38664613489?pr=721
3.87s https://github.com/ruby/setup-ruby/actions/runs/13820508511/job/38664557503?pr=721
2.46s https://github.com/ruby/setup-ruby/actions/runs/13820508511/job/38664568863?pr=721

But, we do Print Ruby version ruby --version a second time after for sanity checking and clarity, and that one seems then faster: 0.33-0.37s, so it's the first ruby --version which is very slow.
And indeed before this change e.g. 2.20s https://github.com/ruby/setup-ruby/actions/runs/13788121949/job/38560974142

So not a big increase in overall time.

@eregon eregon merged commit f0a4d6b into ruby:master Mar 12, 2025
226 of 227 checks passed
@eregon eregon linked an issue Mar 12, 2025 that may be closed by this pull request
@headius
Copy link
Contributor Author

headius commented Mar 12, 2025

That first invocation is likely slow just because the JVM itself has to be paged in. I'll contemplate how to do this check more quickly in the future.

Thank you for the assistance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Choose appropriate minimum JDK for JRuby versions
2 participants