ARTEMIS-5896 Bump ErrorProne to 2.48.0 & limit to JDK25+

[jbertram]

Aside from the upgrade, this restricts ErrorProne to Java 25 and beyond. Technically speaking, it could run on 21, but that also requires a JDK parameter that is exclusively for 21. Restricting to 25 is the simplest solution without any meaningful down-sides.

[gemmellr]

I didnt really like the idea of this since folks may have existing setups that use 17 / 21 with it enabled currently and will then silently no longer get these checks even though they may still think they are (the build time difference, and lack of log spam, would be hints...but still not everyone will spot it changing).

Of course, I didnt particularly like any of the alternatives either (such as making it fail in those cases, or even using different versions for different JDKs, and they hadnt even done the 'requires additional flag for JDK21' change last time I looked either) which is why I hadnt done anything about it since #5824. Hmm..

[jbertram]

We could add a blurb in versions.adoc so folks know it's only enabled on 25 now. There's no great options here, just less bad.

[gemmellr]

Renaming the Jira, e.g 'Update to ErrorProne 2.47.0 and restrict to JDK25+' (or reversed order) would also help convey it via release notes.

The CI config should also be updated to stop trying to enable it on 17/21 if knowing it can never work:

artemis/.github/workflows/build.yml

Line 119 in 6b455f4

mvn -s .github/maven-settings.xml -DskipTests -Derrorprone -Pdev -Pjmh -Popenwire-tests -DskipActiveMQ5Tests -Pcompatibility-tests -DskipCompatibilityTests -Dshade-plugin-create-sources=true install

This change will also mean that the JDK 17/21 Checks runs always finish way before the JDK25 Checks run and will not have grabbed ErrorProne, so their cache updates will always win and not contain ErrorProne (they typically already win, by far less, but it doenst matter currently) , meaning the JDK25 builds will then download ErrorProne on every run. Could try to see if there is anything that can be added to the priming at

artemis/.github/workflows/build.yml

Lines 167 to 170 in 6b455f4

	- name: Additional Cache Priming
	run: |
	cd artemis
	mvn -s .github/maven-settings.xml clean verify -Prelease -Denforcer.skip -pl "artemis-unit-test-support,org.apache.activemq:artemis-junit-5"

to equalise things. Dont really want to have JDK-specific caches as it would eat into the cache quota and cause frequent churn. Could also just restrict it so only the JDK25 Checks job stores the cache, though I have previously preferred the 'competition' so any sporadic env issue on one JDK job doesnt stop the cache update.

[jbertram]

I think this is as far as I can take this. I have no idea about the CI cache thing.

[gemmellr]

2.52.0 now

[gemmellr]

Java 25+

[gemmellr]

I'll take a look at the cache thing next week. Since its just 1 plugin dep I think we can just merge regardless after the couple tiny fixes above.

[gemmellr]

I did look into the caching bit, and came up with a change that mostly handles it (not quite perfectly, there are a few poms that still need downloaded for older errorprone bits, due to the needs of dependency resolution..will look into avoiding that another time). I pushed the commit up to my fork at https://github.com/gemmellr/artemis/commits/refs/heads/jbertram-ARTEMIS-5896/, along with a rebase of yours where I just removed the versions.adoc changes due to all the conflicts now present. If you like the added change I could push them here, or you can pull them into your branch. Happy just to squash them on final merge either way.

Thinking about it, I think it may actually make sense just to omit the versions.adoc changes. It is after all the user-manual rather developer manual. With the Jira now more detailed about the change, there is also now a specific release note of the behaviour change unlike originally. What do you think?

(I also found an unrelated existing cache priming issue from the TLP switch that I fixed on main in 47b0efb)

[jbertram]

I pushed updates to resolve all the issues.

I see your point about the User Manual, but I still like having it in there to let users know that the developer experience matters to us and hopefully encourage folks to get involved. At the very least, I don't think it's hurting anything.

[gemmellr]

Fair enough. Did you see my caching change in https://github.com/gemmellr/artemis/commits/refs/heads/jbertram-ARTEMIS-5896/ ? I'd like it to go in the same commit so either I could push it here or you could pull it?

[jbertram]

@gemmellr, I did not see it. Thanks for the heads-up. I'll pull it in and push -f soon.