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.

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. It does not change the supported Java version or the byte code that is being generated.

Also updates the parent pom to 4.74 (most recent) and the plugin bill of materials to the most recent version.

Supersedes the following pull requests:

• Bump plugin from 4.53 to 4.65 #226
• Bump bom-2.361.x from 1766.v0b_f2a_f7d0b_1d to 2102.v854b_fec19c92 #224

Testing done

Confirmed tests pass with Java 21.

Submitter checklist

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

[MarkEWaite]

@andresrc or @amuniz or @escoem would you be willing to label and merge this pull request so that the plugin tests Java 21 in its standard configuration? No need for a release, just a merge.

[amuniz]

It does not change the supported Java version or the byte code that is being generated.

What would be the bytecode version of the release artifacts? I guess that would still be 11 (as set in https://github.com/jenkinsci/plugin-pom/blob/587d52ab4a35a3243b550c64fa7035f6c379921e/pom.xml#L61, right)

[amuniz]

What's the rationale behind this? Why 17 on Windows (and not 11, for example)?

[MarkEWaite]

Thanks for asking. There are several reasons why this change chooses to test with Java 21 and Java 17 without testing Java 11 on ci.jenkins.io.

• Java 11 byte code is generated by the Java 17 and Java 21 compilers due to the configuration of the plugin parent pom. Java 11 byte code is thus being tested with Java 17 and Java 21 runtimes
• Java 11 compilation and test is performed for this plugin at least once a week in the plugin compatibility tests that are part of the Jenkins plugin bill of materials. The 200+ plugins included in the plugin bill of materials are acting as "safety checks" in case there is some surprise due to not compiling with Java 11 on ci.jenkins.io . Many of the plugins in the plugin BOM enabled this pattern 4-6 weeks ago. We've seen no failures due to the removal of Java 11 compilation and test on ci.jenkins.io
• It is important to keep infrastructure costs as low as we can for ci.jenkins.io . Testing only one Windows configuration and one Linux configuration is a way of reducing those infrastructure costs. Choosing Java 17 and Java 21 improves the JDK coverage and assures that we're "looking forward"

[amuniz]

test with Java 21 and Java 17 without testing Java 11 on ci.jenkins.io

Then you forgot to remove the Java 11 configuration entry there in the Jenkinsfile?

[MarkEWaite]

Then you forgot to remove the Java 11 configuration entry there in the Jenkinsfile?

Thanks for catching that. Fixed in a26f4c1

[MarkEWaite]

It does not change the supported Java version or the byte code that is being generated.

What would be the bytecode version of the release artifacts? I guess that would still be 11 (as set in https://github.com/jenkinsci/plugin-pom/blob/587d52ab4a35a3243b550c64fa7035f6c379921e/pom.xml#L61, right)

That's correct. The ci.jenkins.io jobs compile and test but don't release new versions of the plugin. New releases are performed with Java 11 using the continuous delivery process.