[pull] master from google:master #247
Open
+131,961
−94,108
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Bumps the github-actions group with 2 updates: [actions/setup-java](https://github.com/actions/setup-java) and [github/codeql-action](https://github.com/github/codeql-action). Updates `actions/setup-java` from 4.6.0 to 4.7.0 - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@7a6d8a8...3a4f6e1) Updates `github/codeql-action` from 3.28.5 to 3.28.8 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@f6091c0...dd74661) Fixes #7640 RELNOTES=n/a PiperOrigin-RevId: 722739671
RELNOTES=n/a PiperOrigin-RevId: 722783843
This appears to cut ~10% off the runtime of our internal suite for `common.collect`. RELNOTES=n/a PiperOrigin-RevId: 722792128
It hasn't actually used "mocks" in the sense of "things from a mocking framework" since cl/85631779, which (confusingly) appears to have been the CL that _added_ the "mocks" comment (to replace a previous `@GwtIncompatible` comment about `withFallback`, which wasn't available under GWT until then). (Probably the author had switched away from using a mocking framework during development but then forgotten to remove `@GwtIncompatible` afterward.) It looks like I carried that comment over from `withFallback` to `catchingAsync` in cl/86180055, and then I added a corresponding TODO in cl/116759522. None of that seems to have been necessary. RELNOTES=n/a PiperOrigin-RevId: 723210249
RELNOTES=`net`: Added `image/avif` to `MediaType` PiperOrigin-RevId: 723988216
Compare cl/713006636. (Also, better document the similar code in `AbstractFuture`.) Note that I also evaluated performance with `VarHandle`, and I found it no better. (Maybe we did a similar experiment with `Unsafe` way back when and came to a similar conclusion?) Note that that's all based on _JVM_ performance (and on benchmarks that are not necessarily great). It's possible that Android it worth a further look someday. But our only option there _today_ might be `Unsafe`, and new usages of `Unsafe` would be moving backward. RELNOTES=n/a PiperOrigin-RevId: 724013501
…k overflow, which sometimes hoses subsequent tests or crashes Android. Remove existing attempted workarounds for such trouble. Run some tests under Android now that we can. RELNOTES=n/a PiperOrigin-RevId: 724380185
The implementation code expects `Comparable` implementations to throw `ClassCastException`s when trying to compare to objects of the wrong type. Kotlin/Native `Comparable`s don’t make this guarantee yet (This is expected to change when https://youtrack.jetbrains.com/issue/KT-71001/ is fixed). The assertions are preventing us from making a compiler flag change that changes the behavior that made these assertions pass accidentally. PiperOrigin-RevId: 725264702
Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action). Updates `github/codeql-action` from 3.28.8 to 3.28.9 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@dd74661...9e8d078) Fixes #7652 RELNOTES=n/a PiperOrigin-RevId: 725311401
RELNOTES=n/a PiperOrigin-RevId: 725318466
This is the first piece of #7094, which is progress toward [modularization](#2970): javac (rightly or wrongly) wants a version number that starts with a number. We saw this previously [with Error Prone](google/error-prone#4311 (comment)) and [with JSpecify](jspecify/jspecify@0d39a0e). Relates-To: elide-dev/jpms#1 Signed-off-by: Sam Gammon <[email protected]> RELNOTES=n/a PiperOrigin-RevId: 725625326
RELNOTES=n/a PiperOrigin-RevId: 725640704
… new methods depending on java time) RELNOTES=n/a PiperOrigin-RevId: 725660700
…nings. The `TreeBasedTable` overrides come from cl/16105641. I verified that the methods still appear in the Javadoc when I remove the overrides. (Maven didn't want to regenerate the Javadoc until I ran `clean`....) RELNOTES=n/a PiperOrigin-RevId: 725677309
RELNOTES=n/a PiperOrigin-RevId: 725684361
RELNOTES=n/a PiperOrigin-RevId: 725697082
RELNOTES=n/a PiperOrigin-RevId: 725740741
This prepares us to potentially add `java.io.Serial` to them at some point. Mostly, this CL adds `@GwtIncompatible` and/or `@J2ktIncompatible`. We have already needed the latter previously need for `serialVersionUID` fields in _inner_ classes, such as in cl/605627910. But now we may need them because `java.io.Serial` is not (currently) available under those environments. It's possible that I added the annotations in some cases in which they aren't necessary. I also left a comment in one class where I noticed a `serialVersionUID` field in one flavor but not the other. I ended up ignoring at least one other such class because that one was an implementation of an immutable collection, the implementations of which sometimes vary significantly between flavors. RELNOTES=n/a PiperOrigin-RevId: 725785821
RELNOTES=n/a PiperOrigin-RevId: 725859649
It's kind of amazing how much this improves readability in some cases. (Also, use `getOrDefault` in one place where we can, and suppress some suggestions to use it in places where we can't.) RELNOTES=n/a PiperOrigin-RevId: 725869779
It turns out that we'd changed our choice of `Queue` in `MultimapsTest` once previously in cl/16428259 _without updating the clever comment about it later in the file_ 😱 RELNOTES=n/a PiperOrigin-RevId: 726065051
RELNOTES=n/a PiperOrigin-RevId: 726090734
RELNOTES=n/a PiperOrigin-RevId: 726095812
This is the next piece of #7094, which is progress toward [modularization](#2970). I've modified this CL somewhat from the original version so that I can deploy a new version of `failureaccess` without needing to make any updates to `guava-parent` first. `failureaccess` does still use `guava-parent` (and I've bumped it to use the newest released version) for its configuration for Sonatype, Javadoc, etc. But I've inlined all the configuration that I need for the modularization. I did note a few differences from the original version: - This version includes `LICENSE` under `META-INF`, both in the main jar and in the sources jars. - This version uses a different configuration for Javadoc, I assume because my recent changes there didn't make it into 33.4.0. I also notice that _neither_ version contains `module-info.java` in its source jar. We could presumably fix that in the future if anyone is interested. (And while this isn't strictly related, I do notice that we could consider also releasing a modularized version of `listenablefuture` someday.) I have tested with: ``` $ JAVA_HOME=$HOME/.m2/jdks/jdk-17.0.13+11 ./mvnw clean install -Psonatype-oss-release -Dmaven.test.redirectTestOutputToFile=true -Dsurefire.printSummary=false -Drelease -f futures/failureaccess ``` (Some of those flags aren't necessary, but I found it easiest to copy what our release script does for "normal" releases.) I would use `deploy` instead of `install` for the real thing. Relates-To: elide-dev/jpms#1 Signed-off-by: Sam Gammon <[email protected]> RELNOTES=Changed the `failureaccess` jar to be a modular jar. PiperOrigin-RevId: 726100871
[`@Serial`](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/Serial.html) was added in Java 14, but it has only `SOURCE` retention, so it requires Java 14+ only [at _build_ time](#6549). Guava continues to support Java 8 at runtime, and it already has required a higher version (though perhaps only Java 9+?) to build. Still, if this change causes people trouble, it is easy enough for us to include `@Serial` only in our Google-internal source or even to back out the change entirely. (Part of the purpose of this change is to identify any such trouble before we add any features that require newer versions of Java to build "for real.") Alternatively, if this change goes well, we can consider using `@Serial` on _all_ eligible APIs. RELNOTES=n/a PiperOrigin-RevId: 726154745
…ings. RELNOTES=n/a PiperOrigin-RevId: 726167935
…nings. RELNOTES=n/a PiperOrigin-RevId: 726172349
…quality warnings. RELNOTES=n/a PiperOrigin-RevId: 726178790
RELNOTES=n/a PiperOrigin-RevId: 791690517
…r GWT-RPC support. RELNOTES=n/a PiperOrigin-RevId: 791740625
And add a missing space in `BiMap`. RELNOTES=n/a PiperOrigin-RevId: 791747174
RELNOTES=n/a PiperOrigin-RevId: 792172203
This used to matter to our Maven build, but it stopped mattering back in cl/105596491. RELNOTES=n/a PiperOrigin-RevId: 792182756
I skipped `ImmediateFuture`, since I don't want to deal with [the spying problems I'd encountered previously](https://github.com/google/guava/blob/4eb712cd7401086ebb48107de7515258ddc12c4b/guava/src/com/google/common/util/concurrent/ImmediateFuture.java#L29). I also ended up backing off from `SameThreadScheduledExecutorService`, which led to similar problems. I also skipped [`Promise` in the web (GWT/J2CL) copy of `ListenableFuture`](https://github.com/google/guava/blob/4eb712cd7401086ebb48107de7515258ddc12c4b/guava-gwt/src-super/com/google/common/util/concurrent/super/com/google/common/util/concurrent/ListenableFuture.java#L83) because I don't know what the implications of `final` are there. RELNOTES=n/a PiperOrigin-RevId: 792194355
…-level class. (We could apply it to some more deeply nested classes, too, but I don't want to go out of my way to do so: `private` would be redundant for any classes that are "effectively private.") Plus, address a few Error Prone warnings in the backport-only `ObjectCountHashMap`. Notably, delete `ObjectCountHashMap.MapEntry.setCount`, which was introduced in cl/181210213 but never used (because we always use `ObjectCountHashMap.setValue`, I think). RELNOTES=n/a PiperOrigin-RevId: 792628431
…benchmark. RELNOTES=n/a PiperOrigin-RevId: 792670746
RELNOTES=n/a PiperOrigin-RevId: 792829911
RELNOTES=n/a PiperOrigin-RevId: 792835335
This reduces memory usage (and slightly reduces CPU usage). I may end up attempting a followup in which we avoid using scratch entirely, but I want to prioritize landing _some_ improvement, and I'm starting with this approach because it is Clearly and Obviously Correct, No Chance for Bugs Here. (Also, I don't trust myself to get the benchmarking command right when comparing two pending CLs.) (If someone is using `AbstractByteHasher` across multiple threads without proper synchronization, then this CL could change the behavior from "incorrect results" to "NullPointerException." I think that that case is unlikely to come up, but I acknowledge it.) RELNOTES=n/a PiperOrigin-RevId: 792993210
…tilityClass warnings. RELNOTES=n/a PiperOrigin-RevId: 793360913
It stopped being set in cl/711476575, and it was somewhat incorrect even before that. Closes #7916 RELNOTES=n/a PiperOrigin-RevId: 793703141
And sneak in a few other simplifications, mostly to remove explicit type arguments. Fixes #7930 RELNOTES=n/a PiperOrigin-RevId: 793754837
… warning. RELNOTES=n/a PiperOrigin-RevId: 793778774
Fixes #7938 RELNOTES=n/a PiperOrigin-RevId: 793787039
RELNOTES=update documentation to link references to "unique" to our definition PiperOrigin-RevId: 793809726
…t through `MethodHandle`. This became possible with #6549. See #6549 (comment) and the next couple posts. We still use reflection in `Crc32CSupplier.pickFunction()` to determine whether to use enter this `ChecksumType.CRC_32C` code path or to instead use `ABSTRACT_HASH_FUNCTION`. RELNOTES=n/a PiperOrigin-RevId: 793810002
RELNOTES=n/a PiperOrigin-RevId: 793811806
RELNOTES=n/a PiperOrigin-RevId: 794124488
RELNOTES=n/a PiperOrigin-RevId: 794128644
…le`. That way, when the rendered Javadoc lists `Table` under "All implemented interfaces," it lists it with `@Nullable` on the type argument. Currently, Javadoc does not include `@Nullable` because we explicitly declare only `extends ArrayTable<R, C, @nullable V>`, where `ArrayTable` in turn `implements Table<R, C, V>`. That is not enough for Javadoc because Java doesn't know how substitution works for arbitrary custom type systems. (I think this relates to [JDK-8042981](https://bugs.openjdk.org/browse/JDK-8042981).) RELNOTES=n/a PiperOrigin-RevId: 794690990
RELNOTES=n/a PiperOrigin-RevId: 794719933
RELNOTES=n/a PiperOrigin-RevId: 799230389
….sonatype.org/publish/publish-portal-maven/#publishingserverid) to its default value. RELNOTES=n/a PiperOrigin-RevId: 799337152
When the method is called with an actual array argument, rather than as varargs, assigning into that array is at best surprising. It may also cause an `ArrayStoreException` if the component type of the array is not compatible with `String`. RELNOTES=`Strings.lenientFormat` no longer assigns into its varargs array argument. PiperOrigin-RevId: 800096793
…th.checkedSubtract()`, and `LongMath.checkedMultiply()`. RELNOTES=n/a PiperOrigin-RevId: 800924555
RELNOTES=n/a PiperOrigin-RevId: 801495847
…JDK 8. Guava continues to support users who build and run their own code under JDK 8; this is [only about how we build Guava ourselves](#6549). RELNOTES=n/a PiperOrigin-RevId: 802195145
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )