dep: update minimum java version from 1.8 to 21

[flavorjones]

What problem is this PR intended to solve?

Github Actions started failing on jruby-head builds this week with an error message like:

  bad class file: /home/runner/.rubies/jruby-head/lib/jruby.jar(/org/jruby/Ruby.class)
    class file has wrong version 65.0, should be 61.0

Example failure: https://github.com/sparklemotion/nokogiri/actions/runs/13852274600/job/38789085283#step:4:17

If I understand correctly, the class file version is correlated with the JDK version, so I'm trying this to see if it fixes the issues with jruby-head.

See related commit 86652b1 which updated the minimum from 1.7 to 1.8 in 2024, and 08e5560 which updated the minimum from 1.6 to 1.7 in 2020.

@headius am I doing this right, and what would you recommend as far as timing of when to drop support for 1.8 in Nokogiri?

[headius]

Hey thanks for the ping!

I had hoped you might see things just work but perhaps there's more improvement needed for setup-ruby. In ruby/setup-ruby#721 and ruby/setup-ruby#722 we modified the install to try running JRuby with the default JAVA_HOME, and if it doesn't work we choose the installed Java 21 to run with. That should make things work with JRuby 10, which is compiled for 21+.

Nokogiri should not drop support for Java 8 (1.8) until we're fully done with JRuby 9.4.x, which won't happen until next year at the earliest. The released gem should be built and released with 8 on JRuby 9.4. But for testing against JRuby 10 (which is jruby-head now in setup-ruby), you'll want to run with 21. Nokogiri can be compiled with any release, but tests will need to run with 21 for JRuby.

I am going into a meeting but we can chat through this config later.

[flavorjones]

I see. OK, I've updated this PR to make the min version conditional on the JRuby version:

def java_min_version
  if java? && JRUBY_VERSION.start_with?("10.")
    "1.9"
  else
    "1.8"
  end
end

Let's see what CI says. The "upstream" workflow had to be kicked off manually, it's here:

https://github.com/sparklemotion/nokogiri/actions/runs/13865422261

[flavorjones]

Narp. Failure is the same, at https://github.com/sparklemotion/nokogiri/actions/runs/13865422261/job/38803387178

OK, I'm stuck and must have misunderstood the symptom/failure. LMK if you know what I should be doing.

[headius]

Your conditional logic is correct but for a few details:

• There is no Java 1.9, it's 9,
• JRuby 10 requires Java 21 minimum, not 9.
• The nokogiri extension can be build with Java 8 (or 1.8, same thing) and run on JRuby 10 with Java 21+ just fine.
• We need the released extension to continue to support Java 8, so it should be built and released with JRuby 9.4 still.

I think if you make the min version for JRuby 10 to be Java "21" it should work ok.

FWIW I did confirm recently that nokogiri CI tests run properly on a local JRuby 10 (with Java 21+), so this is just a matter of getting the env set up right.

[headius]

It may also be possible to build the extension for Java 8/1.8 using JRuby 10 on Java 21, but there's always a chance that dependencies on Java 21 APIs might sneak in.

[flavorjones]

Bumped to 21. Upstream workflow (manual run) is https://github.com/sparklemotion/nokogiri/actions/runs/13913631993

[flavorjones]

@headius From failed job https://github.com/sparklemotion/nokogiri/actions/runs/13913631993/job/38932577442#step:4:9

error: invalid target release: 21

If there are other variations on this that I should try, please let me know. I'm a bit lost at this point.

[headius]

@flavorjones Sorry again about this. We're going to be dealing with some growing pains here since GHA defaults to Java 17.

That is basically the problem here. Even though we set up JRuby to use Java 21, the java command in path still points at Java 17 by default.

Would it be ok if I tried to come up with a PR to fix jruby-head for you tomorrow (18 March)? I think to get your CI green the best short-term fix would be to switch to jruby-9.4 and we'll turn jruby-head back on once I have the details worked out.

[flavorjones]

@headius - What's failing is only the jruby-head job (which I test along with other upstream edge builds (cruby, libxml, html5lib) in the "upstream" workflow). The jruby 9.4 job is fine. Not urgent!

[headius]

@flavorjones I pushed #3477 to remove jar-dependencies pinning and fully switch the upstream build to Java 21 using the setup-java action (https://github.com/actions/setup-java). The jruby-head build is green there.