Use Java 25 for Javadoc links, too.

(followup to 5752811)

I may have waffled over whether to link to 21 (most recent LTS) or 23 (most recent STS) back in 166bb20.

- I can see an argument that 21 is more likely to be what users want, since they're more likely to actually be using it.
- But by linking to the newest STS, we can given advice about the newest Java APIs, like the `Reader` APIs in 9a179fc.
- And anyway, no matter which version we link to, we're going to pick the "wrong" one for someone. (For all I know, there might be more people on, say, Java 17 than on Java 21.)
- Plus, the Javadoc UX has in general improved over the years, so newer is better in that sense.
- Finally, there is probably value in matching the Javadoc version that we're using to generate Javadoc with the version that we're linking to: I think that, in the past, we've seen disagreements over whether links end `#foo()` or `#foo--` and maybe occasional other changes in link format. (Another change in link format was b/305225234 / [JDK-8318093](https://bugs.openjdk.org/browse/JDK-8318093). But this may be more likely to be example of an improvement in Javadoc over time than a case in which we'd actually see a broken link from the disagreement.)

RELNOTES=n/a
PiperOrigin-RevId: 813748397

Author: cpovirk

android/guava/pom.xml

@@ -191,7 +191,7 @@
           </tags>
 
           <!-- TODO(cpovirk): Move this to the parent after making the package-list files available there. -->
-          <!-- We add the link ourselves so that we can choose Java 21 over the version that -source suggests. -->
+          <!-- We add the link ourselves so that we can choose Java 25 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. -->
@@ -201,7 +201,7 @@
             </offlineLink>
           </offlineLinks>
           <links>
-            <link>https://docs.oracle.com/en/java/javase/21/docs/api/</link>
+            <link>https://docs.oracle.com/en/java/javase/25/docs/api/</link>
             <link>https://errorprone.info/api/latest/</link>
             <link>https://jspecify.dev/docs/api/</link>
           </links>

guava/pom.xml

@@ -184,7 +184,7 @@
           </tags>
 
           <!-- TODO(cpovirk): Move this to the parent after making the package-list files available there. -->
-          <!-- We add the link ourselves so that we can choose Java 21 over the version that -source suggests. -->
+          <!-- We add the link ourselves so that we can choose Java 25 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. -->
@@ -194,7 +194,7 @@
             </offlineLink>
           </offlineLinks>
           <links>
-            <link>https://docs.oracle.com/en/java/javase/21/docs/api/</link>
+            <link>https://docs.oracle.com/en/java/javase/25/docs/api/</link>
             <link>https://errorprone.info/api/latest/</link>
             <link>https://jspecify.dev/docs/api/</link>
           </links>