Add jruby on windows-11-arm

[ntkme]

JRuby >=9.4.4.0 supports windows on arm: https://github.com/jruby/jruby/releases/tag/9.4.4.0

GitHub Actions recently added new windows-11-arm runner for OSS: https://github.blog/changelog/2025-04-14-windows-arm64-hosted-runners-now-available-in-public-preview/

Name windows-11-arm is normalized to windows-11-arm64 to align similar to how ubuntu and mac runner's names get normalized.

[eregon]

Nice, it works: https://github.com/ruby/jruby-dev-builder/actions/runs/14650305762/job/41114265330

Although it's quite slow: https://github.com/ruby/jruby-dev-builder/actions/runs/14650305762/usage

I also noticed the version string is very confusing:

jruby 10.0.1.0-SNAPSHOT (3.4.2) 2025-04-24 3165c38e39 OpenJDK 64-Bit Server VM 21.0.6+7-LTS on 21.0.6+7-LTS +indy +jit [x86_64-mswin32]

but we are on windows-arm64.
I filed jruby/jruby#8797 for it.

[ntkme]

@eregon I think that's because we're running x64 JDK under emulation? - The version correctly reports arm64 when I use setup-java instead of the environment variable hack.

[eregon]

Mmh, so windows-11-arm has a JAVA_HOME_21_X64 variable and that's a x64 JDK?
Does it also have a JAVA_HOME_21_arm64 variable?
If yes to both maybe we should try JAVA_HOME_21_arm64 first then, IIRC when I checked only one of these variables was ever set per runner, but maybe that's not the case on windows-11-arm.

[ntkme]

So this is indeed x64 JDK, it's actually printed in the log here: https://github.com/ruby/jruby-dev-builder/actions/runs/14650305762/job/41114265330#step:18:6

JAVA_HOME: C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\21.0.6-7.0\x64

I also tested with the two variable swapped and it still ended up with the same JAVA_HOME... I think only x64 JDK is preinstalled on arm64 image right now.

[eregon]

Indeed: https://github.com/eregon/actions-shell/actions/runs/14660751736/job/41144475809
That looks like a bug to me.
And that means we don't have a JDK21 with the correct (native) architecture installed then on windows-11-arm, which is a blocker for setup-ruby (where all system dependencies must be pre-installed to be fast enough).
Could you search/file an issue at https://github.com/actions/runner-images for this?

[eregon]

I also checked and C:\\hostedtoolcache\\windows only has C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\21.0.6-7.0\x64, no ...\arm64 or so, see https://github.com/eregon/actions-shell/actions/runs/14660941691/job/41145080963#step:4:5 (and other runs on that repo for more details).

[eregon]

For now I will remove windows-11-arm from the matrix in this repo since it's effectively running the tests on the wrong architecture (which makes it pointless to run on windows-11-arm) and there seems to be no way to fix it so that setup-ruby could get a native JDK 21 (without needing to download one) on windows-11-arm without GitHub improving their runner images.

[ntkme]

It’s actually this repository: https://github.com/actions/partner-runner-images/issues

You can see lots of existing issues about other tools only having x64 version preinstalled.

I wouldn’t really consider this as a blocker:

1. Running x64 emulation is slow, but functionally woks.
2. Users can still run setup-java before setup-ruby to install arm64 JDK to get the best performance.

[eregon]

I wouldn’t really consider this as a blocker:

1. Running x64 emulation is slow, but functionally woks.

But that seems pointless to me at least, might as well run on x64 Windows like windows-2025 then.
Also anything that relates to native code or using system libraries is likely to break as well, I think the value of this is zero or very close.

2. Users can still run setup-java before setup-ruby to install arm64 JDK to get the best performance.

I prefer to not provide JRuby on windows-11-arm in setup-ruby than to provide it with a gigantic trap.

If you want it, please file the issue upstream, probably many others would agree this needs to be done anyway (the only valid reason I see would be if JDK 21 doesn't support windows-arm64 but that doesn't seem to be the case).

And then let's focus on supporting CRuby on windows-arm64 until that's resolved.