Link to Java 21 Javadoc instead of Java 9.

(Compare cl/696632561 for Truth. I verified that the Truth change worked in post-submit CI, and (as you'll see) I did some work to verify that this Guava change works in local testing.)

This CL addresses the "linking" part of #6790 but not the "inheriting" part.

I was having trouble getting this to work with the JDK in the `<linkoffline>` section, so I moved it to the `<link>` section. (But not before first accidentally creating a _second_ `<link>` section, which Maven seems to have chosen to ignore without error. See also my other complaints in a comment in the actual `pom.xml`.) Fortunately, we don't need to use `<linkoffline>` for the JDK anymore because we no longer need to have the JDK in the same section as JSR-305 now that `javax.annotation` isn't part of the JDK anymore (and thus there's no longer a conflict about whether the JDK or JSR-305 gets to "claim" it and thus there's no need to resolve it through ordering, which we can control only within sections, not across sections).

Somewhere in the course of working through that, I upgraded `maven-javadoc-plugin` to 3.11.1. That may or may not have turned out to be necessary, but it's probably more likely to help than to hurt.

RELNOTES=n/a
PiperOrigin-RevId: 696636564

Author: cpovirk

android/guava/pom.xml

@@ -153,7 +153,7 @@
           </tags>
 
           <!-- TODO(cpovirk): Move this to the parent after making the package-list files available there. -->
-          <!-- We add the link ourselves, both so that we can choose Java 9 over the version that -source suggests and so that we can solve the JSR305 problem described below. -->
+          <!-- We add the link ourselves so that we can choose Java 21 over the version that -source suggests. -->
           <detectJavaApiLink>false</detectJavaApiLink>
           <offlineLinks>
             <!-- We need local copies of some of these for 2 reasons: a User-Agent problem (https://stackoverflow.com/a/47891403/28465) and an SSL problem (https://issues.apache.org/jira/browse/MJAVADOC-507). If we choose to work around the User-Agent problem, we can go back to <links>, sidestepping the SSL problem. -->
@@ -166,18 +166,13 @@
               <url>https://static.javadoc.io/com.google.j2objc/j2objc-annotations/1.1/</url>
               <location>${project.basedir}/javadoc-link/j2objc-annotations</location>
             </offlineLink>
-            <!-- The JDK doc must be listed after JSR305 (and as an <offlineLink>, not a <link>) so that JSR305 "claims" javax.annotation. -->
-            <offlineLink>
-              <url>https://docs.oracle.com/javase/9/docs/api/</url>
-              <location>https://docs.oracle.com/javase/9/docs/api/</location>
-            </offlineLink>
-            <!-- The Checker Framework likewise would claim javax.annotations, despite providing only a subset of the JSR305 annotations, so it must likewise come after JSR305. -->
             <offlineLink>
               <url>https://checkerframework.org/api/</url>
               <location>${project.basedir}/javadoc-link/checker-framework</location>
             </offlineLink>
           </offlineLinks>
           <links>
+            <link>https://docs.oracle.com/javase/21/docs/api/</link>
             <link>https://errorprone.info/api/latest/</link>
           </links>
           <overview>../../overview.html</overview>

android/pom.xml

@@ -319,7 +319,7 @@
         </plugin>
         <plugin>
           <artifactId>maven-javadoc-plugin</artifactId>
-          <version>3.8.0</version>
+          <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). -->
             <jdkToolchain>

guava/pom.xml

@@ -153,7 +153,7 @@
           </tags>
 
           <!-- TODO(cpovirk): Move this to the parent after making the package-list files available there. -->
-          <!-- We add the link ourselves, both so that we can choose Java 9 over the version that -source suggests and so that we can solve the JSR305 problem described below. -->
+          <!-- We add the link ourselves so that we can choose Java 21 over the version that -source suggests. -->
           <detectJavaApiLink>false</detectJavaApiLink>
           <offlineLinks>
             <!-- We need local copies of some of these for 2 reasons: a User-Agent problem (https://stackoverflow.com/a/47891403/28465) and an SSL problem (https://issues.apache.org/jira/browse/MJAVADOC-507). If we choose to work around the User-Agent problem, we can go back to <links>, sidestepping the SSL problem. -->
@@ -166,18 +166,13 @@
               <url>https://static.javadoc.io/com.google.j2objc/j2objc-annotations/1.1/</url>
               <location>${project.basedir}/javadoc-link/j2objc-annotations</location>
             </offlineLink>
-            <!-- The JDK doc must be listed after JSR305 (and as an <offlineLink>, not a <link>) so that JSR305 "claims" javax.annotation. -->
-            <offlineLink>
-              <url>https://docs.oracle.com/javase/9/docs/api/</url>
-              <location>https://docs.oracle.com/javase/9/docs/api/</location>
-            </offlineLink>
-            <!-- The Checker Framework likewise would claim javax.annotations, despite providing only a subset of the JSR305 annotations, so it must likewise come after JSR305. -->
             <offlineLink>
               <url>https://checkerframework.org/api/</url>
               <location>${project.basedir}/javadoc-link/checker-framework</location>
             </offlineLink>
           </offlineLinks>
           <links>
+            <link>https://docs.oracle.com/javase/21/docs/api/</link>
             <link>https://errorprone.info/api/latest/</link>
           </links>
           <overview>../overview.html</overview>

pom.xml

@@ -314,7 +314,7 @@
         </plugin>
         <plugin>
           <artifactId>maven-javadoc-plugin</artifactId>
-          <version>3.8.0</version>
+          <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). -->
             <jdkToolchain>