[v1.3.x] Introduce compatibility with JRuby 10

[chadlwilson]

JRuby 10 compat

• Removes unnecessary jruby.compat.version which I believe has not been needed for a long time on JRuby 9+ and is removed on JRuby 10
• Runs all unit tests/specs and appraisals with JRuby 10 / Java 21.
• Adds appraisal test for Rails 8.0, which is (theoretically) supported by JRuby 10's language compatibility level

[chadlwilson]

@kares What do you think about dropping 9.3.x tests with 1.3.0? Not intending to intentionally break compatibility, but it avoids some annoying hacking around with old bundler versions during testing.

Given 9.3 only targets Ruby 2.6 compatibility which is 3 years beyond EOL (as a syntax, relevant for compatibility with Rack/rails versions etc) I can't really see the need to worry about 9.3 now?

[kares]

What do you think about dropping 9.3.x tests with 1.3.0? Not intending to intentionally break compatibility, but it avoids some annoying hacking around with old bundler versions during testing.

If it's causing headaches than I am 👍.
We can direct users towards 1.2 if they're stuck with 9.3 and if needed do an extra bug fix release or two from a 1.2-stable support branch (was planning to do that later based on whether any reports will come in).

There's also more stuff to remove that I am finding jruby-rack still has around (e.g. JMS queue support).
Anyhow if you're done here I would just merge this in...

[chadlwilson]

If we include #267 I believe that'd imply dropping 9.4 support entirely - which would probably reduce the user base significantly due to the the decision to require Java 21 (which then requires all sorts of other upgrades and implied servlet changes to get a compatible webserver), which would likely imply needing to keep 1.2.x longer in parallel. Personally I'd probably prefer doing that kind of stuff in a later 1.4 (along with Jakarta change perhaps) so there are upgrade paths that don't require changing more things at the same time than necessary.

And yes, there is still a lot of old workarounds and deprecations still in the code (e.g logging deprecations) that could be cleaned up by someone with a little more historical context than I and understanding of the goals of the logging changes in 1.2.x.

Moving to a later servlet API version (even 4.0 might be a decent path forward (as the latest javax.servlet version).

[kares]

If we include #267 I believe that'd imply dropping 9.4 support entirely

Personally, would prefer not to do that, I agree with your thoughts on the subject.
The way I had historically approached jruby-rack (and other projects such as jruby-openssl as well) is to have a long (conservative) tail for older versions. 9.3 seems like worth dropping since we have a hopefully decent 1.2 now with your back-ports from 1.1 included.

On the jakarta move I really do not have any definite answer, would be worth trying to support both with tools such as the Jakarta migration tool (from Tomcat) but that means having to move some scripted Ruby to a Java extension. I think we should just pass on that until someone has a 💰 for us 😉 or everyone is on jakarta.servlet.

Moving to a later servlet API version (even 4.0 might be a decent path forward (as the latest javax.servlet version).

Yeah sure, I am not up-to-date with the changes in 4.0 but sounds like it might be about time.
Also probably jump to Java 11 as minimum, would allow us to release jruby-rack as a proper module.

[mjansing]

This sounds great. Is there a plan when to release v1.3 or even a pre-release without servlet v4?