Hard-code Java versions for plugins other than maven-surefire-plugin.

[copybara-service]

Hard-code Java versions for plugins other than maven-surefire-plugin.

In particular:

• Use JDK 22 for compilation (also, for any other affected plugins) to avoid a JDK 11 bug.
  • Another way to avoid that bug would be to use JDK 8, which would also provide a --release-like compatibility guarantee. However, that could complicate using newer APIs conditionally. And of course we'd expect JDK 8 to be buggier than JDK 22. (In fact, we still have a workaround or two for JDK 8 bugs (with a brand new one coming in cl/655556207), and we could now remove those—assuming that none of our users use JDK 8 to build Guava outside of our Maven build.) JDK 22 also supports new versions of Error Prone, while JDK 8 does not.
  • This change also allows us to simplify our Error Prone configuration, which until now needed different profiles in order to support both JDK 8 and JDK 9+. We could now upgrade Error Prone, but I haven't done so yet. There are probably other simplifications that we could perform, as well, such as maven-javadoc-plugin.additionalJOptions.
  • Originally, I'd set up this CL to explicitly set only the toolchain of maven-compiler-plugin to 22. I had it using 11 for any other plugins (just Animal Sniffer, maybe?), I think from when I was trying to get toolchains to take effect at all. I've since changed this CL to set the default toolchain to 22 while still including overrides for maven-javadoc-plugin and maven-surefire-plugin.
• Continue to use JDK 11 for Javadoc, as we're doing now because of problems with at least JDK 21.
  • What matters might actually be the version used by JDiff, which comes from the version in the linked ci.yml file. But since we're using JDK 11 currently for docs in general, I'm sticking with that for now. Still, we should consider upgrading the version used for Javadoc generation. But this CL is already complicated enough....
  • When we hard-code JDK 11, we need to change the <source>${java.specification.version}</source> line: That would otherwise set (for example) -source 17 when running Maven under JDK 17, and JDK 11 wouldn't recognize it. As I recall, the java.specification.version usage was from the days in which we tried to inherit Javadoc from the JDK. Inheritance had stopped working, and we ripped it out in cl/614693592. I first tried going with the default from the JDK whose Javadoc binary we're using, which (again) will now be 11. But that led to a problem in org.codehaus.plexus.languages.java.jpms.CmdModuleNameExtractor, which apparently tries to look up the module name for the -source 11 run but uses the Maven run's JDK instead of the Javadoc toolchain or Maven toolchain. So now I've set it to 8 to match what we use for maven-compiler-plugin. (I thought I had remembered that maven-javadoc-plugin defaulted to matching maven-compiler-plugin, even though that's weird. Maybe the two actually just read from the same Maven property or something, or maybe the behavior changed.)

Some other thing I'm wondering:

• I wonder if we should activate(?) some of the plugins, including the new toolchain plugins, in the <plugins> (not just <pluginManagement>) section of the parent pom.xml. Might that save us from having to do so in each separate pom.xml? (We might actually mostly get away with activating(?) them only in the main guava build: That downloads and registers the toolchains, and then at least the other projects' per-plugin toolchain configuration probably finds them? But for the more general configuration to work, I think we at least need to activate(?) maven-toolchains-plugin in each? I haven't experimented a ton with this.)
• I forgot the other thing while I was typing :(

(See also these notes.)

Fixes #7331

RELNOTES=n/a

[cpovirk]

I checked the GitHub Actions results. All succeeded (notably including "Generate latest docs") except for "Publish snapshot," which failed (as it occasionally does) with "status code: 502, reason phrase: Bad Gateway (502)."

There's an associated gh-pages commit. And https://guava.dev/api still looks probably correct, as does https://guava.dev/releases/snapshot-jre/api/diffs/.

So I think we're good.