Make it possible to actually use (e.g.) -Dsurefire.toolchain.version=21 to set the Java version for tests, and do so in CI. (The property value still _defaults_ to the JDK that you use to run Maven, so passing the flag is not _necessary_.)

This lets us use whatever Java version we want\[1\] for executing Maven itself—and thus for executing any plugins that aren't toolchain-aware. (I even hacked up our toolchain configuration to run tests under Java 24, and it worked.) I've changed our CI to do that, too, by always using Java 23. (This makes the explicit choice of Java 23 for _javac_ redundant under CI, as well as on our Google workstations. However, it can be useful for anyone who builds Guava locally while having an older JDK as the default version.)

Notably, that means that we can use a new version (like Java 23) for running the GWT plugin, which lets us upgrade to GWT 2.12.1 (cl/711417161), which uses an Eclipse compiler with bytecode version 55 (Java 11)\[2\]. (This means that users who build `guava-gwt` locally with Java 8 will need to [upgrade their build JDK to at least Java 11](https://github.com/google/guava/issues/6549)—or skip building `guava-gwt` if they don't need it.)

That GWT upgrade is in turn necessary in order for us to be able to use use [JSpecify annotations](jspecify/jspecify#239) from our GWT artifact.

In theory, this could also prepare us for further changes, like more easily running tests under multiple versions during our release process (in addition to how we already do so for CI), though there are already other ways of doing that by hacking up our release script or `pom.xml`. And I'm not sure that I'd really want to do that, anyway. (See also some notes that I've added to cl/639128020.)

I also did some related cleanup:

- Our `--no-module-directories` configuration probably became Just Wrong back in cl/655647768: It should be based on the version that we use to build Javadoc (which is currently always 11), not the version that Maven is running under. It probably mostly doesn't matter because we probably mostly don't try to run Javadoc under other versions, but I'd like to be able to do so, so this is a step forward.
- `-Djava.security.manager=allow` is not necessary now that we've cleaned up our usages of `SecurityManager`. (And that's fortunate, as it seems difficult to [active a profile based on a range of values of an arbitrary "my test JRE version" property](https://issues.apache.org/jira/browse/MNG-3328), as opposed to activate it based on the JDK that Maven is running under.)

Fixes #7492 (by making `setup-java` download all the toolchains that we need)

\[1\] I mean, I suspect that Maven support lags new JDKs somewhat, and I've seen problems with other versions (as documented in cl/488902996). But at least we don't have to use the same Java version for executing Maven itself as we do for executing tests.

\[2\] That was causing this error:

```
[INFO] --- gwt:2.10.0:compile (gwt-compile) @ guava-gwt ---
Error: [ERROR] Unexpected internal compiler error
[INFO] java.lang.UnsupportedClassVersionError: org/eclipse/jdt/internal/compiler/classfmt/ClassFormatException has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
[INFO] 	at java.lang.ClassLoader.defineClass1(Native Method)
[INFO] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
[INFO] 	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
[INFO] 	at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
[INFO] 	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
[INFO] 	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
[INFO] 	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
[INFO] 	at java.security.AccessController.doPrivileged(Native Method)
[INFO] 	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
[INFO] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
[INFO] 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
[INFO] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
[INFO] 	at com.google.gwt.dev.javac.CompilationStateBuilder.doBuildFrom(CompilationStateBuilder.java:488)
[INFO] 	at com.google.gwt.dev.javac.CompilationStateBuilder.buildFrom(CompilationStateBuilder.java:464)
[INFO] 	at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:426)
[INFO] 	at com.google.gwt.dev.Precompile.validate(Precompile.java:145)
[INFO] 	at com.google.gwt.dev.Compiler.compile(Compiler.java:184)
[INFO] 	at com.google.gwt.dev.Compiler.compile(Compiler.java:143)
[INFO] 	at com.google.gwt.dev.Compiler.compile(Compiler.java:132)
[INFO] 	at com.google.gwt.dev.Compiler$1.run(Compiler.java:110)
[INFO] 	at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:55)
[INFO] 	at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:50)
[INFO] 	at com.google.gwt.dev.Compiler.main(Compiler.java:113)
```
RELNOTES=n/a
PiperOrigin-RevId: 711476575

Author: cpovirk

.github/workflows/ci.yml

@@ -37,19 +37,26 @@ jobs:
           access_token: ${{ github.token }}
       - name: 'Check out repository'
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
-      - name: 'Set up JDK ${{ matrix.java }}'
+      # When we specify multiple JDKs, the final one becomes the default, which is used to execute Maven itself.
+      # Our Maven configuration then specifies different JDKs to use for some of the steps:
+      # - 11 for building Javadoc
+      # - 23 for running javac (to help people who build Guava locally and might not use a recent JDK to run Maven)
+      # (Note that we also use Java 11 for running our Gradle integration tests. But we run those only when we are already going to run tests under Java 11.)
+      - name: 'Set up JDKs'
         uses: actions/setup-java@8df1039502a15bceb9433410b1a100fbe190c53b # v4.5.0
-
         with:
-          java-version: ${{ matrix.java }}
+          java-version: |
+            ${{ matrix.java }}
+            11
+            23
           distribution: 'zulu'
           cache: 'maven'
       - name: 'Install'
         shell: bash
         run: ./mvnw -B -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn install -U -DskipTests=true -f $ROOT_POM
       - name: 'Test'
         shell: bash
-        run: ./mvnw -B -P!standard-with-extra-repos verify -U -Dmaven.javadoc.skip=true -f $ROOT_POM
+        run: ./mvnw -B -P!standard-with-extra-repos verify -U -Dmaven.javadoc.skip=true -Dsurefire.toolchain.version=${{ matrix.java }} -f $ROOT_POM
       - name: 'Print Surefire reports'
         # Note: Normally a step won't run if the job has failed, but this causes it to
         if: ${{ failure() }}

android/pom.xml

@@ -13,9 +13,8 @@
   <url>https://github.com/google/guava</url>
   <properties>
     <!--
-    We could override this to change which version we run tests under.
-    However, I think that our -Djava.security.manager=allow profile is based on the *Maven* JDK.
-    If we want to use overrides here, we should change that profile to also be based on surefire.toolchain.version.
+    When building Guava, you can pass (e.g.) `-Dsurefire.toolchain.version=21` to change which version to run tests under.
+    You may find that you need to use Java 11+ to *build* Guava, but it continues to work under Java 8, and you can run tests to verify that, as we do.
     -->
     <surefire.toolchain.version>${java.specification.version}</surefire.toolchain.version>
     <!-- Override this with -Dtest.include="**/SomeTest.java" on the CLI -->
@@ -28,7 +27,19 @@
     <maven-javadoc-plugin.additionalJOptions></maven-javadoc-plugin.additionalJOptions>
     <project.build.outputTimestamp>2024-01-02T00:00:00Z</project.build.outputTimestamp>
     <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
-    <test.add.opens></test.add.opens>
+    <!--
+    Some tests need reflective access to the internals of these packages. It is only the
+    tests themselves and not the code being tested that needs that access, though there's no
+    obvious way to ensure that.
+
+    We could consider arranging things so that only the tests we know need this would get
+    the add-opens. Right now that doesn't seem worth the effort, though.
+    -->
+    <test.add.opens>
+      --add-opens java.base/java.lang=ALL-UNNAMED
+      --add-opens java.base/java.util=ALL-UNNAMED
+      --add-opens java.base/sun.security.jca=ALL-UNNAMED
+    </test.add.opens>
     <test.add.args></test.add.args>
     <module.status>integration</module.status>
     <variant.jvmEnvironment>android</variant.jvmEnvironment>
@@ -321,7 +332,7 @@
           <artifactId>maven-javadoc-plugin</artifactId>
           <version>3.11.1</version>
           <configuration>
-            <!-- TODO: b/286965322 - Use a newer version (probably the default toolchain we set up?) if it doesn't break Javadoc (including causing trouble for our later run of JDiff, which we do outside Maven, during snapshots/releases). -->
+            <!-- TODO: b/286965322 - Use a newer version (probably the default javac toolchain we set up?) if it doesn't break Javadoc (including causing trouble for our later run of JDiff, which we do outside Maven, during snapshots/releases). At that point, we'll likely want to remove the no-module-directories additionalJOption, as documented below. -->
             <jdkToolchain>
               <version>11</version>
               <vendor>zulu</vendor>
@@ -337,7 +348,14 @@
             </additionalOptions>
             <linksource>true</linksource>
             <source>8</source>
-            <additionalJOption>${maven-javadoc-plugin.additionalJOptions}</additionalJOption>
+            <!--
+                Required to make symbol search work correctly in the generated pages under JDK 11-12.
+
+                This flag does not exist on 9-10 and 13+ (https://bugs.openjdk.java.net/browse/JDK-8215582).
+
+                Consider removing it once our Javadoc generation is migrated to a recent JDK.
+             -->
+            <additionalJOption>--no-module-directories</additionalJOption>
           </configuration>
           <executions>
             <execution>
@@ -448,76 +466,113 @@
   </dependencyManagement>
   <profiles>
     <profile>
-        <id>sonatype-oss-release</id>
-        <build>
-          <plugins>
-            <plugin>
-              <artifactId>maven-gpg-plugin</artifactId>
-              <version>3.0.1</version>
-              <executions>
-                <execution>
-                  <id>sign-artifacts</id>
-                  <phase>verify</phase>
-                  <goals>
-                    <goal>sign</goal>
-                  </goals>
-                </execution>
-              </executions>
-            </plugin>
-          </plugins>
+      <id>sonatype-oss-release</id>
+      <build>
+        <plugins>
+          <plugin>
+            <artifactId>maven-gpg-plugin</artifactId>
+            <version>3.0.1</version>
+            <executions>
+              <execution>
+                <id>sign-artifacts</id>
+                <phase>verify</phase>
+                <goals>
+                  <goal>sign</goal>
+                </goals>
+              </execution>
+            </executions>
+          </plugin>
+        </plugins>
       </build>
     </profile>
     <profile>
-      <!--
-          Passes JDK 11-12-specific `no-module-directories` flag to Javadoc tool,
-          which is required to make symbol search work correctly in the generated
-          pages.
-
-          This flag does not exist on 9-10 and 13+ (https://bugs.openjdk.java.net/browse/JDK-8215582).
-
-          Consider removing it once our release and test scripts are migrated to a recent JDK (17+).
-       -->
-      <id>javadocs-jdk11-12</id>
+      <id>suppress-open-jre-modules-for-toolchain-1.8</id>
       <activation>
-        <jdk>[11,13)</jdk>
+        <property>
+          <name>surefire.toolchain.version</name>
+          <!-- the value provided by java.specification.version -->
+          <value>1.8</value>
+        </property>
       </activation>
       <properties>
-        <maven-javadoc-plugin.additionalJOptions>--no-module-directories</maven-javadoc-plugin.additionalJOptions>
+        <test.add.opens></test.add.opens>
       </properties>
     </profile>
     <profile>
-      <id>open-jre-modules</id>
+      <id>suppress-open-jre-modules-for-toolchain-8</id>
       <activation>
-        <jdk>[9,]</jdk>
+        <property>
+          <name>surefire.toolchain.version</name>
+          <!-- the value provided by GitHub CI (which maybe we could even change, but supporting "8" seems nice for any users who try pass that value manually) -->
+          <value>8</value>
+        </property>
       </activation>
       <properties>
-        <!--
-            Some tests need reflective access to the internals of these packages. It is only the
-            tests themselves and not the code being tested that needs that access, though there's no
-            obvious way to ensure that.
-
-            We could consider arranging things so that only the tests we know need this would get
-            the add-opens. Right now that doesn't seem worth the effort, though.
-        -->
-        <test.add.opens>
-          --add-opens java.base/java.lang=ALL-UNNAMED
-          --add-opens java.base/java.util=ALL-UNNAMED
-          --add-opens java.base/sun.security.jca=ALL-UNNAMED
-        </test.add.opens>
+        <test.add.opens></test.add.opens>
       </properties>
     </profile>
+    <!-- The Gradle integration tests need to set JAVA_HOME to the location of Java 11. The following profile extracts that location. -->
     <profile>
-      <id>javac-for-jvm18plus</id>
-      <activation>
-        <!--
-            In order to build and run the tests against JDK 18+, we need to pass java.security.manager=allow, to make
-            the deprecated 'java.lang.SecurityManager' available for use.
-         -->
-        <jdk>[18,]</jdk>
-      </activation>
-      <properties>
-        <test.add.args>-Djava.security.manager=allow</test.add.args>
-      </properties>
+      <id>print-java-11-home</id>
+      <build>
+        <plugins>
+          <plugin>
+            <artifactId>maven-toolchains-plugin</artifactId>
+            <executions>
+              <execution>
+                <id>select-java-11</id>
+                <phase>initialize</phase>
+                <goals>
+                  <goal>toolchain</goal>
+                </goals>
+              </execution>
+            </executions>
+            <configuration>
+              <toolchains>
+                <jdk>
+                  <version>11</version>
+                  <vendor>zulu</vendor>
+                </jdk>
+              </toolchains>
+            </configuration>
+          </plugin>
+          <plugin>
+            <groupId>com.diamondq.maven</groupId>
+            <artifactId>javahome-resolver-maven-plugin</artifactId>
+            <version>1.0.2</version>
+            <executions>
+              <execution>
+                <id>resolve-java-11</id>
+                <phase>initialize</phase>
+                <goals>
+                  <goal>resolve</goal>
+                </goals>
+              </execution>
+            </executions>
+          </plugin>
+          <plugin>
+            <groupId>org.codehaus.mojo</groupId>
+            <artifactId>exec-maven-plugin</artifactId>
+            <version>3.5.0</version>
+            <executions>
+              <execution>
+                <id>print-java-11-home</id>
+                <phase>initialize</phase>
+                <goals>
+                  <goal>exec</goal>
+                </goals>
+                <configuration>
+                  <executable>echo</executable>
+                  <arguments>
+                    <argument>${javaHome}</argument>
+                  </arguments>
+                  <outputFile>${project.build.directory}/java_11_home</outputFile>
+                </configuration>
+              </execution>
+            </executions>
+          </plugin>
+        </plugins>
+      </build>
     </profile>
   </profiles>
 </project>