> Independently of that, we can consider switching the default JDK for ci.jenkins.io `buildPlugin` from 8 to 11. Even if your plugin supports older baselines and Java 8, running the build on JDK 11 is typically fine, since `-release 8` will ensure the right bytecode and even prevent the infamous `ByteBuffer` problem.
Alas the bytecode produced is not exactly the same and this is legal. This bytecode difference trips up spotbugs (causing several new false positives) that have no option other than to be suppressed, so this change will likely cause "unrelated" build failures somewhere. I generally do not like build failures coming from "unrelated" changes, and to may any build change should really be configured and controlled as source (so it can be pre validated). That said most of my plugins are already up to date so this should be a non issue for me. On the simificationn of the parent pom I am +1 /James On Mon, 28 Nov 2022, 19:38 'Jesse Glick' via Jenkins Developers, < [email protected]> wrote: > Your proposal sounds great to me, and thanks for volunteering to implement > the changes. I think a late-2022 timeline (sometime after 2.375.1 has been > released) makes sense—if there is some advantage in waiting longer, I do > not get what. The only likely drawback for plugin maintainers who > deliberately wish to stay on a pre-2.361.x baseline is that Dependabot (if > configured) will offer `plugin-pom` updates that fail CI builds, which is > not so bad since the release notes will explain why, and the PR and its > replacements can simply be ignored indefinitely. (And of course you will > not get access to new stuff in the toolchain, but that seems fair.) > > Independently of that, we can consider switching the default JDK for > ci.jenkins.io `buildPlugin` from 8 to 11. Even if your plugin supports > older baselines and Java 8, running the build on JDK 11 is typically fine, > since `-release 8` will ensure the right bytecode and even prevent the > infamous `ByteBuffer` problem. The likely issues: you will lose Java 8 test > coverage (while gaining 11 test coverage, which is more important!); and > occasionally some tool like `javadoc` will be stricter (in a way you ought > to fix anyway though you might have preferred to take your time). > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1mdb5zZx7%3D%2B2M%2BgtUrCMXtfCQcJ406WhvQojhx5NTbXw%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1mdb5zZx7%3D%2B2M%2BgtUrCMXtfCQcJ406WhvQojhx5NTbXw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPzq3pc7fpcFtwkV%3DbqBfQxvgb_2%3DN-Eh_kf96t735C1r_3qJQ%40mail.gmail.com.
