Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Work around Javadoc and JDiff bugs caused by the existence of two `co…
…pyOf(E[])` declared in the same class. (These methods already existed and already triggered the [Javadoc bug](https://bugs.openjdk.org/browse/JDK-8318093) (see, e.g., [`ImmutableSortedSet` for 32.1.3-jre](https://guava.dev/releases/32.1.3-jre/api/docs/com/google/common/collect/ImmutableSortedSet.html), but cl/572427348 caused them to trigger the more severe JDiff bug.) Although those methods are legal overloads with different erasures, Javadoc gives them the same ID, "#copyOf(E%5B%5D)," so the links in the method summary both go to the same method's details. (Luckily, it's at least the method that people are likely to want.) Under newer versions of Javadoc than the one we use, Javadoc actually generates only one `copyOf(E[])` entry in the method summary! I hope it's the right one, but I haven't checked. Additionally, JDiff has been [crashing](https://github.com/google/guava/actions/runs/6476993159/job/17586928450) during our doc-snapshot workflow since cl/572427348: ``` JDiff: reading the new API in from file '/tmp/guava-snapshot-temp.Dap/jre/Guava_HEAD-jre-SNAPSHOT.xml'...Error: duplicate comment id: com.google.common.collect.ImmutableSortedMultiset.copyOf_changed(E[]) ``` So JDiff is making the same mistake as Javadoc. Luckily, we can work around this by renaming the type parameter to "Z" in one case. RELNOTES=n/a PiperOrigin-RevId: 573801260
- Loading branch information