Switch JAVA_HOME to 21 for JRuby by headius · Pull Request #721 · ruby/setup-ruby

headius · 2025-03-11T20:53:17Z

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 · 2025-03-11T20:56:24Z

@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 · 2025-03-11T20:58:27Z

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

eregon · 2025-03-11T21:12:12Z

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 · 2025-03-11T21:22:02Z

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 · 2025-03-11T21:31:47Z

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

headius · 2025-03-11T21:36:19Z

@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 · 2025-03-11T21:36:27Z

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 · 2025-03-11T21:44:06Z

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 · 2025-03-11T21:44:36Z

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 · 2025-03-11T21:47:36Z

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 · 2025-03-11T21:48:02Z

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 · 2025-03-11T21:50:02Z

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 · 2025-03-11T21:52:06Z

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 · 2025-03-11T22:12:06Z

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 · 2025-03-11T22:26:14Z

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.

eregon

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

eregon · 2025-03-12T08:49:32Z

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 · 2025-03-12T17:27:51Z

Changes from latest review are in and green.

eregon · 2025-03-12T19:55:23Z

 const core = require('@actions/core')
 const tc = require('@actions/tool-cache')
+const exec = require('@actions/exec')
+const common = require('./common')


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 · 2025-03-12T20:00:42Z

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 · 2025-03-12T20:18:44Z

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 versionruby --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.

headius · 2025-03-12T20:37:23Z

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.

headius force-pushed the java_21_for_jruby branch from 22e5251 to 061b308Compare March 11, 2025 20:53

Switch JAVA_HOME to 21 for JRuby
4158eb5
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 force-pushed the java_21_for_jruby branch from 061b308 to 4158eb5Compare March 11, 2025 20:57

headius added 2 commits March 11, 2025 16:04

Add group and logging to JAVA_HOME setup
ef749c3

Generate index from updated setup
745e010

eregon reviewed Mar 11, 2025
View reviewed changes

Comment threadcommon.js Outdated

Only upcase x64 platform
ef40e17
The JAVA_HOME_* variables use 'arm64' on ARM.

headius force-pushed the java_21_for_jruby branch from 5d3234e to ef40e17Compare March 11, 2025 21:23

Use 'X64' variable everywhere except macos
efa9afc

eregon reviewed Mar 11, 2025
View reviewed changes

Comment threadcommon.js Outdated
Comment threadcommon.js Outdated

eregon reviewed Mar 11, 2025
View reviewed changes

Comment threadruby-builder.js Outdated

headius added 2 commits March 11, 2025 16:55

Only change JAVA_HOME if JRuby fails to start
2502fcd

Cleanup based on review
7ffdbb4

headius force-pushed the java_21_for_jruby branch from 29d6dd3 to 7ffdbb4Compare March 11, 2025 22:11

Set up exec constant for JRuby check
f3baf96

eregon reviewed Mar 12, 2025
View reviewed changes

Comment threadcommon.js Outdated
Comment threadindex.js Outdated
Comment threadcommon.js Outdated

headius added 3 commits March 12, 2025 11:43

Move JAVA_HOME setup into install
5c0bbf7

Clean up rogue semicolon
2e82a48

Use measure to track JAVA_HOME setup time
dad12fe

headius force-pushed the java_21_for_jruby branch from d69712b to dad12feCompare March 12, 2025 17:19

eregon approved these changes Mar 12, 2025
View reviewed changes

eregon reviewed Mar 12, 2025
View reviewed changes

Comment threadcommon.js Outdated
Comment threadcommon.js Outdated

Apply suggestions from code review
9b80b4d

eregon force-pushed the java_21_for_jruby branch from 9877756 to 9b80b4dCompare March 12, 2025 20:05

eregon merged commit f0a4d6b into ruby:masterMar 12, 2025

eregon linked an issue Mar 12, 2025 that may be closed by this pull request
Choose appropriate minimum JDK for JRuby versions #718
Closed

eregon mentioned this pull request Mar 12, 2025
Switch back to jruby master ruby/jruby-dev-builder#10
Merged

headius mentioned this pull request Mar 14, 2025
dep: update minimum java version from 1.8 to 21 sparklemotion/nokogiri#3468
Closed

MSP-Greg mentioned this pull request Apr 12, 2025
javaextensiontask.rb - check javac path using JAVA_HOMErake-compiler/rake-compiler#247
Merged

eregon mentioned this pull request Apr 18, 2025
Install JDK 21 for JRuby 10 ruby/ruby-builder#22
Merged

Uh oh!

Uh oh!

Conversation

headius commented Mar 11, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

headius commented Mar 11, 2025

Uh oh!

headius commented Mar 11, 2025

Uh oh!

Uh oh!

eregon commented Mar 11, 2025

Uh oh!

headius commented Mar 11, 2025

Uh oh!

headius commented Mar 11, 2025

Uh oh!

headius commented Mar 11, 2025

Uh oh!

eregon commented Mar 11, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

headius commented Mar 11, 2025

Uh oh!

eregon commented Mar 11, 2025

Uh oh!

headius commented Mar 11, 2025

Uh oh!

eregon commented Mar 11, 2025

Uh oh!

eregon commented Mar 11, 2025

Uh oh!

headius commented Mar 11, 2025

Uh oh!

headius commented Mar 11, 2025

Uh oh!

headius commented Mar 11, 2025

Uh oh!

eregon left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

eregon commented Mar 12, 2025

Uh oh!

headius commented Mar 12, 2025

Uh oh!

eregonMar 12, 2025

Choose a reason for hiding this comment

Uh oh!

eregon commented Mar 12, 2025

Uh oh!

Uh oh!

Uh oh!

eregon commented Mar 12, 2025

Uh oh!

headius commented Mar 12, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

headius commented Mar 11, 2025•
edited
Loading

eregon commented Mar 11, 2025•
edited
Loading