aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-11-30Declare "redundant" overrides of all our package-private `writeReplace` methods.cpovirk
If users request for an optimizer to keep one of our classes in `com.google.common.collect` but permit it to move supertypes or subtypes of that class into other packages, then those `writeReplace` methods are no longer treated as overrides, and serialization breaks. Normally, optimizers are smart enough not to break overrides. However, in the case of serialization, `writeReplace` is invoked reflectively inside the serialization system, which also performs its own access checks. This means that some optimizers don't know that `writeReplace` is called. So, even if they are instructed to keep all methods of that name, they don't know to preserve their override-ness. In the particular case we were seeing, `ImmutableCollection` and `RegularImmutableList` were ending up in the default package, while `ImmutableList` was staying in `common.collect`. That might sound like it should still work: Serializing an `RegularImmutableList` instance should invoke the package-private `ImmutableCollection.writeReplace` method. However, if I'm understanding correctly, Java serialization is buggy (or at least surprising relative to normal inheritance): `ObjectStreamClass.getInheritableMethod`, upon finding the package-private `ImmutableList.writeReplace` method (which is _not_ relevant to `RegularImmutableList` anymore because it now appears in a different package), [gives up on looking for `writeReplace`](https://github.com/openjdk/jdk/blob/570dffb104fc37f053fcdf38a24aa2cabdc921c0/src/java.base/share/classes/java/io/ObjectStreamClass.java#L1518) instead of continuing to scan for `writeReplace` in any grandparent+ types that live in the same package. RELNOTES=n/a PiperOrigin-RevId: 586777576
2023-11-30Bump actions/setup-java from 3.13.0 to 4.0.0dependabot[bot]
Bumps [actions/setup-java](https://github.com/actions/setup-java) from 3.13.0 to 4.0.0. - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](https://github.com/actions/setup-java/compare/0ab4596768b603586c0de567f2430c30f5b0d2b0...387ac29b308b003ca37ba93a6cab5eb57c8f5f93) Fixes #6854 RELNOTES=n/a PiperOrigin-RevId: 586764572
2023-11-27Correct Javadoc for CacheBuilder.weigher.lowasser
RELNOTES=n/a PiperOrigin-RevId: 585780506
2023-11-27Reenable some tests externally.cpovirk
The GWT bug that caused trouble for them was fixed long ago. PiperOrigin-RevId: 585709530
2023-11-24Bump github/codeql-action from 2.22.7 to 2.22.8dependabot[bot]
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 2.22.7 to 2.22.8. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](https://github.com/github/codeql-action/compare/66b90a5db151a8042fa97405c6cf843bbe433f7b...407ffafae6a767df3e0230c3df91b6443ae8df75) Fixes #6849 RELNOTES=n/a PiperOrigin-RevId: 585091604
2023-11-21Work around or suppress forthcoming nullness errors.cpovirk
This CL also provides a little more progress toward https://github.com/google/guava/issues/3679: One of the workarounds involves removing a call to the long-obsolete `Iterators.cast`, and I went ahead and removed the method itself, too. RELNOTES=n/a PiperOrigin-RevId: 584417248
2023-11-21Defer logger construction in AbstractFuture.Google Java Core Libraries
The uses are somewhat exceptional (i.e. SEVERE logs), but the initialization of the logger itself is relatively costly. RELNOTES=Defer logger construction in AbstractFuture. PiperOrigin-RevId: 584415298
2023-11-21Check compatibility against the Android SDK (including [always-desugared ↵cpovirk
APIs](https://github.com/open-toast/gummy-bears#android) but still not opt-in library desugaring) instead of the JDK. Fixes https://github.com/google/guava/issues/4005 RELNOTES=n/a PiperOrigin-RevId: 584349750
2023-11-17Update http:// links to https:// if available.Chaoren Lin
Also update some links that have been migrated. Context: #6839. RELNOTES=n/a PiperOrigin-RevId: 583431708
2023-11-17Update Public Suffix data.Google Java Core Libraries
RELNOTES=n/a PiperOrigin-RevId: 583388879
2023-11-16Bump github/codeql-action from 2.22.6 to 2.22.7dependabot[bot]
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 2.22.6 to 2.22.7. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](https://github.com/github/codeql-action/compare/689fdc5193eeb735ecb2e52e819e3382876f93f4...66b90a5db151a8042fa97405c6cf843bbe433f7b) Fixes #6837 RELNOTES=n/a PiperOrigin-RevId: 583054642
2023-11-16Make our Android builds work with an Android bootclasspath.cpovirk
Notably: - Remove all usages of `AnnotatedType` from the Android flavor. - Make `NullPointerTester` a no-op in the Android flavor (instead of only in the Android flavor _when running under an Android VM_). - (This requires removing its tests from the Android flavor entirely, rather than merely skipping them during our internal Android-VM test runs.) In both cases, these changes apply only to (a) guava-android and (b) our actual internal _Android_ builds. In contrast, in the internal copy of the backport _that we test under a JRE_, the `AnnotatedType` APIs are still in place, and `NullPointerTester` still runs. RELNOTES=`reflect`: In `guava-android` only, removed `Invokable.getAnnotatedReturnType()` and `Parameter.getAnnotatedType()`. These methods never worked in an Android VM, and to reflect that, they were born `@Deprecated`, `@Beta`, and `@DoNotCall`. They're now preventing us from rolling out some new Android compatibility testing. PiperOrigin-RevId: 583032835
2023-11-14Bump github/codeql-action from 2.22.5 to 2.22.6dependabot[bot]
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 2.22.5 to 2.22.6. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](https://github.com/github/codeql-action/compare/74483a38d39275f33fcff5f35b679b5ca4a26a99...689fdc5193eeb735ecb2e52e819e3382876f93f4) Fixes #6833 RELNOTES=n/a PiperOrigin-RevId: 582333368
2023-11-13Withdraw `SequencedCollection` overrides from the public copy of ↵cpovirk
`ImmutableSortedSet`. As far as external users are concerned, this CL is a rollback of cl/575459262. The problem that cl/575459262 was addressing looks like it may be a quirk of Google's internal build setup. We may end up wanting to remove these overrides entirely, so we don't want to commit to them externally by publishing a release with them. Or we may decide to include them both internally and externally. For now, we'll be conservative. RELNOTES=n/a PiperOrigin-RevId: 582099306
2023-11-09Prepare to expose (all?) remaining collectors as part of `guava-android`.cpovirk
This CL is further progress toward https://github.com/google/guava/issues/6567 RELNOTES=n/a PiperOrigin-RevId: 581031659
2023-11-09Provide default instances of `MutableNetwork`.cpovirk
This fixes some flakiness that results from the proxy implementation that we otherwise autogenerate. PiperOrigin-RevId: 580971223
2023-11-08Remove stray `public` keyword.cpovirk
I think it's harmless, too, but I have been wrong about such things before (e.g., b/304502608) :) RELNOTES=n/a PiperOrigin-RevId: 580668074
2023-11-08Document and test how `ImmutableMap.toImmutableMap` behaves when the ↵cpovirk
`mergeFunction` returns `null`. (The test is Google-internal for now because we're in the process of reshuffling our `Collector` tests to make them run under Android as part of https://github.com/google/guava/issues/6567. Also, we skip the test under GWT+J2CL because of a bug in their implementation of `Collectors.toMap`.) This addresses the main part of https://github.com/google/guava/issues/6824, but I'm keeping the bug open as a prompt to recognize our nullness annotations in the future. RELNOTES=n/a PiperOrigin-RevId: 580661189
2023-11-06Link to some discussion of the Android flavor.cpovirk
(somewhat relevant to https://github.com/google/guava/issues/6725 and https://github.com/google/guava/issues/6801, but this CL is about the good things about the Android flavor, not the risks of the JRE flavor) RELNOTES=n/a PiperOrigin-RevId: 579886456
2023-11-04Continuing preparing to make immutable-collection `Collector` APIs available ↵cpovirk
in guava-android (but don't do so yet). This CL is further progress toward https://github.com/google/guava/issues/6567 RELNOTES=n/a PiperOrigin-RevId: 579462040
2023-10-31Document why `EqualsTester.addEqualityGroup` has a `@Nullable` parameter.Éamonn McManus
RELNOTES=n/a PiperOrigin-RevId: 578260904
2023-10-31Upgrade to use Gradle 8.4Google Java Core Libraries
RELNOTES=Upgrade gradle version in sample app to 8.4 PiperOrigin-RevId: 578259506
2023-10-31Prepare to make `ImmutableMultimap` collectors available in guava-android ↵cpovirk
(but don't do so yet). This CL also includes updates to avoid problems with reflection when Java 8+ APIs are not present. That means adding a `serialVersionUID` (so that Java/Android reflection doesn't try to compute one with reflection) and skipping `NullPointerTester` (compare cl/550872250) and some `FauxveridesTest` tests (compare cl/576629272) under Android. This CL is further progress toward https://github.com/google/guava/issues/6567 RELNOTES=n/a PiperOrigin-RevId: 578200572
2023-10-30Remove bogus nullness annotations from cl/575459262.cpovirk
(Four annotations correct out of five isn't too bad...? :)) (continuing progress toward https://github.com/google/guava/issues/6567) RELNOTES=n/a PiperOrigin-RevId: 577938765
2023-10-28Bump github/codeql-action from 2.22.4 to 2.22.5dependabot[bot]
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 2.22.4 to 2.22.5. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](https://github.com/github/codeql-action/compare/49abf0ba24d0b7953cb586944e918a0b92074c80...74483a38d39275f33fcff5f35b679b5ca4a26a99) Fixes #6813 RELNOTES=n/a PiperOrigin-RevId: 577476329
2023-10-27Add "Sec-Ad-Auction-Fetch" header.Google Java Core Libraries
Add "Ad-Auction-Signals" header. Spec: https://wicg.github.io/turtledove/#handling-direct-from-seller-signals. RELNOTES=N/A PiperOrigin-RevId: 577303702
2023-10-27Add some issue and PR templates for Guava.Chaoren Lin
RELNOTES=n/a PiperOrigin-RevId: 577280351
2023-10-27Prepare to make `ImmutableMap.toImmutableMap` available in guava-android ↵cpovirk
(but don't do so yet). This CL also includes updates to avoid problems with reflection when Java 8+ APIs are not present. That means adding a `serialVersionUID` (so that Java/Android reflection doesn't try to compute one with reflection) and skipping `NullPointerTester` (compare cl/550872250) and some `FauxveridesTest` tests (compare cl/576629272) under Android. This CL is further progress toward https://github.com/google/guava/issues/6567 RELNOTES=n/a PiperOrigin-RevId: 577213115
2023-10-26Prepare to make `ImmutableList.toImmutableList` available in guava-android ↵cpovirk
(but don't do so yet). This CL also includes updates to avoid problems with reflection when Java 8+ APIs are not present. That means adding a `serialVersionUID` (so that Java/Android reflection doesn't try to compute one with reflection). (Compare cl/550872250.) This CL is further progress toward https://github.com/google/guava/issues/6567 RELNOTES=n/a PiperOrigin-RevId: 576885237
2023-10-26Add Maven wrapper distribution checksumMarcono1234
Fixes #6807 RELNOTES=n/a PiperOrigin-RevId: 576861414
2023-10-25Make the J2CL version of Doubles/Floats/Ints/ShortsMethodsForWeb types public.Julien Dramaix
RELNOTES=n/a PiperOrigin-RevId: 576698256
2023-10-25Prepare to make `ImmutableSet.toImmutableSet` available in guava-android ↵cpovirk
(but don't do so yet). This includes adding `ImmutableCollection.spliterator()` as a further attempt to shake out any problems that might arise when we make "real" API changes. The method is callable under API Level 24 or higher, under which it overrides the method inherited from `Collection`. (But when last I checked (over 2 years ago!), library desugaring rewrote it to _not_ be an override: b/187166349.) In any case, we don't expect users to call it directly. (Compare cl/543468006.) This CL also includes updates to avoid problems with reflection when Java 8+ APIs are not present. That means adding a `serialVersionUID` (so that Java/Android reflection doesn't try to compute one with reflection) and skipping `NullPointerTester` under Android (though we still run `NullPointerTester` against the Android flavor under a JVM). (I might have added `serialVersionUID` more places than necessary; I'm not sure.) (Compare cl/550872250.) This CL is further progress toward https://github.com/google/guava/issues/6567 (To make this work with some of our Android library-desugaring infrastructure, I had to first implement the new `SequencedCollection` methods in `ImmutableSortedSet`. That happened in cl/575207552.) RELNOTES=n/a PiperOrigin-RevId: 576629272
2023-10-24Mark @JsOptional parameters as @Nullable。Molly Tian
J2CL team is in the process of disallowing JsOptional parameters to be non-nullable to improve type safety. RELNOTES=n/a PiperOrigin-RevId: 576205896
2023-10-24Bump ossf/scorecard-action from 2.3.0 to 2.3.1dependabot[bot]
Bumps [ossf/scorecard-action](https://github.com/ossf/scorecard-action) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/ossf/scorecard-action/releases) - [Changelog](https://github.com/ossf/scorecard-action/blob/main/RELEASE.md) - [Commits](https://github.com/ossf/scorecard-action/compare/483ef80eb98fb506c348f7d62e28055e49fe2398...0864cf19026789058feabb7e87baa5f140aac736) Fixes #6800 RELNOTES=n/a PiperOrigin-RevId: 576188986
2023-10-23Bump github/codeql-action from 2.22.3 to 2.22.4dependabot[bot]
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 2.22.3 to 2.22.4. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](https://github.com/github/codeql-action/compare/0116bc2df50751f9724a2e35ef1f24d22f90e4e1...49abf0ba24d0b7953cb586944e918a0b92074c80) Fixes #6797 RELNOTES=n/a PiperOrigin-RevId: 575878570
2023-10-21Add ↵cpovirk
[`SequencedCollection`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/SequencedCollection.html) methods to `ImmutableSortedSet`. There are a couple reasons that this is maybe kind of nice, and then there's my real motivation for doing it. Reasons that this is maybe kind of nice: - We add `@DoNotCall` and `@Deprecated` to the mutator methods, as usual. - We refine the return type of `reversed()` to `ImmutableSortedSet`. But again, those aren't my real motivation. (If they _were_ my real motivation, you might notice, then there would be no reason for us to override `getFirst()` and `getLast()`.) My _real_ motivation is that we are looking to give `guava-android` APIs that use Java 8+ types in their signatures, such as `ImmutableSet.toImmutableSet`. And as a result of some part of those changes, we start seeing errors in some of our Google-internal build rules. Those errors come because some the desugaring process is inserting its own versions of `getFirst` and friends, versions that refer to the desugar-provided copies of `SortedSet` and `NavigableSet`, which our build process then looks for but cannot find. Since this CL is preparation for adding `ImmutableSet.toImmutableSet`, it constitutes further progress toward https://github.com/google/guava/issues/6567 RELNOTES=`collect`: Added [`SequencedCollection`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/SequencedCollection.html) methods to `ImmutableSortedSet`. PiperOrigin-RevId: 575459262
2023-10-20ensure that Graph/ValueGraph views for a node report empty when that node is ↵ineuwirth
removed from the graph RELNOTES=ensure that Graph/ValueGraph views for a node report empty when that node is removed from the graph PiperOrigin-RevId: 575365844
2023-10-18Bump actions/checkout from 4.1.0 to 4.1.1dependabot[bot]
Bumps [actions/checkout](https://github.com/actions/checkout) from 4.1.0 to 4.1.1. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](https://github.com/actions/checkout/compare/8ade135a41bc03ea155e62e844d188df1ea18608...b4ffde65f46336ab88eb53be808477a3936bae11) Fixes #6791 RELNOTES=n/a PiperOrigin-RevId: 574627784
2023-10-18Update javadocs for `ImmutableList.subList()`.Kurt Alfred Kluever
RELNOTES=n/a PiperOrigin-RevId: 574503150
2023-10-17Make `equals` work when comparing a `cartesianProduct` against another `Set`.Éamonn McManus
In 2012 the parent type of `CartesianSet` was changed from `AbstractSet` to `ForwardingCollection`, with the inadvertent effect that a `CartesianSet` can never compare equal to another `Set` unless that is also a `CartesianSet`. Fixes https://github.com/google/guava/issues/6780. RELNOTES=n/a PiperOrigin-RevId: 574207364
2023-10-17Bump `failureaccess` dep to 1.0.2.cpovirk
Fixes https://github.com/google/guava/issues/6776 RELNOTES=n/a PiperOrigin-RevId: 574207363
2023-10-17Add `.mvn/wrapper/maven-wrapper.jar` to `.gitignore`.cpovirk
It's added by runs of the Maven Wrapper, which was added by cl/573917287. RELNOTES=n/a PiperOrigin-RevId: 574181333
2023-10-16Copy `sonatype-oss-release` configuration from Guava to `failureaccess`.cpovirk
This prevents a `gpg: signing failed: Timeout` error during release. This lets us continue our progress on https://github.com/google/guava/issues/6776. RELNOTES=n/a PiperOrigin-RevId: 573995200
2023-10-16Give `failureaccess` an `Automatic-Module-Name`, and bump its version to ↵cpovirk
1.0.2 to prepare for a release (which we'll then need to update Guava to use). I chose an `Automatic-Module-Name` over an actual `module-info`, even for this dependency-free artifact, because [I can do that without requiring JDK 9+ for builds](https://github.com/google/guava/issues/6549#issuecomment-1761753306). Granted, there would be relatively little harm in requiring JDK 9+ for `failureaccess` builds, since `failureaccess` isn't part of our normal build process. (Guava's build pulls an already released version of `failureaccess`.) Still, it's possible that someone is building both Guava _and_ `failureaccess` with JDK 8, so it may be nice not to break that workflow. Plus, I'm not sure that a proper module definition buys us much (relative to `Automatic-Module-Name`) when we have no deps? Still, I am a bit tempted, if only to try to shake out remaining issues that `module-info` might cause our users. This CL is progress toward fixing https://github.com/google/guava/issues/6776 (or "toward working around a Maven bug," if you prefer). It's also a tiny bit of progress toward modularizing Guava (https://github.com/google/guava/issues/2970), since `failureaccess` is one of its existing unmodularized dependencies. RELNOTES=Added an `Automatic-Module-Name` to `failureaccess`, [Guava's one strong runtime dependency](https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies). PiperOrigin-RevId: 573930127
2023-10-16Begin using Maven Wrapper.cpovirk
I set this up with: ``` mvn org.apache.maven.plugins:maven-wrapper-plugin:3.2.0:wrapper -Dtype=-script -Dmaven=3.9.5 ``` It's not obvious to me whether we'll notice many differences among the 3 non-binary types (`source`, `script`, and `only-script`). I initially went with `only-script`, which is newest, given that it sounded theoretically like it would involve the fewest steps. But I got [an error](https://github.com/google/guava/actions/runs/6536542346/job/17748480689?pr=6783) from the Windows CI: ``` distributionUrl is not valid, must match *-bin.zip or maven-mvnd-*.zip, but found 'https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.9.5/apache-maven-3.9.5-bin.zip ' ``` I assume that this is a newline-related issue. That error message comes from the `only-script` shell script, and there is no such line in the `script` shell script, so I'm now trying `script`. (It's possible that we should be using `mvnw.cmd` under Windows, so maybe nothing will work until I change our CI to do that.... (We got a recommendation for the Maven Wrapper [from Ben Manes](https://groups.google.com/g/guava-discuss/c/e5UVvuM9CP8/m/w2H3CjZ7AQAJ).) There does not yet appear to be a way to [make Dependabot automatically update the version of Maven we use](https://github.com/dependabot/dependabot-core/issues/485) (nor the version of the wrapper itself, though I looked less hard for that because it's less important). We've already not kept up with Maven upgrades very carefully—and we might each be using different Maven versions for all I know!—so this isn't necessarily a huge downgrade. Still, we don't want to fall far behind what's on our machines or GitHub CI, so I've at least set myself a calendar reminder to check back every 6 months. RELNOTES=n/a PiperOrigin-RevId: 573917287
2023-10-16Work around Javadoc and JDiff bugs caused by the existence of two ↵cpovirk
`copyOf(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
2023-10-13Bump github/codeql-action from 2.22.2 to 2.22.3dependabot[bot]
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 2.22.2 to 2.22.3. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](https://github.com/github/codeql-action/compare/d90b8d79de6dc1f58e83a1499aa58d6c93dc28de...0116bc2df50751f9724a2e35ef1f24d22f90e4e1) Fixes #6778 RELNOTES=n/a PiperOrigin-RevId: 573240745
2023-10-13Avoid exposing some types outside the scope in which those types are visible.cpovirk
Java doesn't mind this, but it's not like it's accomplishing anything for us. I've tried to make things `private` where possible and fallen back to making types package-private where necessary. (In `Synchronized`, I made everything package-private for consistency, rather than trying to trace through the class hierarchies to expose only the types that need it.) I also sprinkled in some `final` keywords while I was in the area. RELNOTES=n/a PiperOrigin-RevId: 573211489
2023-10-12Bump github/codeql-action from 2.22.1 to 2.22.2dependabot[bot]
Bumps [github/codeql-action](https://github.com/github/codeql-action) from 2.22.1 to 2.22.2. - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](https://github.com/github/codeql-action/compare/fdcae64e1484d349b3366718cdfef3d404390e85...d90b8d79de6dc1f58e83a1499aa58d6c93dc28de) Fixes #6774 RELNOTES=n/a PiperOrigin-RevId: 572922477
2023-10-11Clarify documentation of transform methods in `ClosingFuture`.Google Java Core Libraries
From reading the documentation of (e.g.) `ClosingFuture#catching`, it seems a caller is not allowed to afterwards call (e.g.) `finishToValueAndCloser`, even though this is totally fine according to the class level documentation. RELNOTES=Clarify documentation of transform methods in `ClosingFuture` PiperOrigin-RevId: 572596268
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-24 15:56:29 +0000