Test with Java 21

[MarkEWaite]

Test with Java 21

Java 21 released Sep 19, 2023. We'd like to announce full support for Java 21 in early October and would like the most used plugins to be compiling and testing with Java 21.

The acceptance test harness and plugin bill of materials tests are already passing with Java 21. This is a further step to improve plugin readiness for use with Java 21 and for development with Java 21.

Not testing Java 11 because Java 11 byte code is being generated by the Java 17 compiler and the Java 21 compiler. The plugin bill of materials runs the tests with Java 11 as well.

Java 11 will be unsupported by Eclipse Temurin and some other Java providers in October 2024. We'll need to move past Java 11 by that time, so this makes the transition in test configuration. It does not change the supported Java version or the byte code that is being generated.

Testing done

Confirmed tests pass with Java 21 on Linux.

Submitter checklist

• [x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• [x] Ensure that the pull request title represents the desired changelog entry
• [x] Please describe what you did
• [x] Link to relevant issues in GitHub or Jira
• [x] Link to relevant pull requests, esp. upstream and downstream changes
• [x] Ensure you have provided tests - that demonstrates feature works or fixes the issue

[dblock]

Should we keep the [platform: 'linux', jdk: 17] test?

[MarkEWaite]

Should we keep the [platform: 'linux', jdk: 17] test?

I'd prefer to not keep the Linux tests of Java 17. We've been intentionally choosing to test the minimum combination of platforms so that we can reduce the cost of ci.jenkins.io jobs. We've been using minimal combinations for many months with no detected issues that were missed due to using the minimum combination of platforms. This is one of those cases where Java's platform independence works in our favor.

[MarkEWaite]

Should we keep the [platform: 'linux', jdk: 17] test?

However, if that's a requirement from you as a maintainer, then I'm willing to make that change in the pull request. I'd rather increase the CI cost this plugin than not test this plugin with Java 21.

[dblock]

It's fine, unless we start introducing JDK 21 code and never catch bugs. I'll merge as is.

[MarkEWaite]

It's fine, unless we start introducing JDK 21 code and never catch bugs. I'll merge as is.

The current tooling will fail compilation if someone attempts to introduce Java 21 code. It generates Java 11 byte code and if an attempt is made to use a Java 21 feature, that will fail in byte code generation. If not at that point, then it will fail in the Java 17 test case.