[pull] master from google:master #247
Open
+129,280
−90,859
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}
Also add a test that validates that the example given for FRQ in its doc comment are sound. We're not deprecating FRQ yet, because `Cleaner` is still fairly recent in the Android world. RELNOTES=We now recommend the standard `Cleaner` class instead of `FinalizableReferenceQueue`, when `Cleaner` is available. PiperOrigin-RevId: 705490132
(followup cl/705490132) The method requires JDK 9+ to build, but our Maven build [always builds with JDK 23](#6549 (comment)). It also requires JDK 9+ to _run_, so I've added code to skip running the test under older versions. Much of my goal here is to shake out any ways that we might cause problems if we begin conditionally using Java 9+ APIs more widely, such as [for `VarHandle`](#6806 (comment)). RELNOTES=n/a PiperOrigin-RevId: 705512728
See #6806 (comment). Changes: - "`SafeAtomicHelper`" is arguably already too generic a name for that class, given that we have a `SynchronizedAtomicHelper` that also avoids using `Unsafe`. It's going to become even more overly generic (and more overly scary) when we likely introduce a `VarHandle`-based alternative. (And maybe we'll even remove the `Unsafe`-based one entirely?) Rename it. - Remove Javadoc from implementation classes, since it merely duplicates that from the superclass. - Fix links in the (package-private) Javadoc. I considered also renaming the `AtomicHelper` methods to match the terminology of `VarHandle`. This would mean only renaming `putThread`+`putNext` to... `setReleaseThread`? `setThreadReleasedly`? `setThreadUsingReleaseAccessMode`? I didn't find anything that I particularly liked. RELNOTES=n/a PiperOrigin-RevId: 705868797
Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action). Updates `github/codeql-action` from 3.27.6 to 3.27.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@aa57810...df409f7) Fixes #7551 RELNOTES=n/a PiperOrigin-RevId: 706810168
RELNOTES=n/a PiperOrigin-RevId: 706818220
…s.openjdk.java.net/browse/JDK-7101822)(?) now that we [build with a JDK after JDK 8](#6549). This follows up on cl/332225001 and cl/643394004. RELNOTES=n/a PiperOrigin-RevId: 706845781
I'm not entirely sure whether these should be necessary, but adding them is the easiest way to resolve some J2KT errors that I'm seeing as I make changes to prepare for using `@NullMarked` in the open-source build. RELNOTES=n/a PiperOrigin-RevId: 707934342
The CL in which I begin using it has gotten very large, so I'm splitting it up where possible. (progress toward jspecify/jspecify#239) RELNOTES=n/a PiperOrigin-RevId: 707938539
This is redundant for now, though it is arguably nice to be explicit. However, my actual motivation is that I expect to use a package-level `@NullMarked` annotation (contrary to my usual recommendation) in order to help external Java 8 users whose tools might be upset by the `@Target(..., MODULE)` that they are more likely to discover if `@NullMarked` appears on individual classes. RELNOTES=n/a PiperOrigin-RevId: 707946250
RELNOTES=n/a PiperOrigin-RevId: 707959746
One thing that I did *not* look at was the various suppressions of JDK bugs in our collection-test-suite-builder tests. It's possible that some of them could be removed, but I didn't want to start trying to figure out whether everything worked under various JDKs, Android, GWT, and J2CL. Fixes #3679 RELNOTES=n/a PiperOrigin-RevId: 707987954
RELNOTES=n/a PiperOrigin-RevId: 707999373
Since these classes are part of the hierarchy for types like `ArrayListMultimap`, we need to annotate them in order for the nullness of those types to be correct. I'd missed them earlier, but as I began to explore package-level `@NullMarked` annotations (which I don't normally recommend but which might be the way to go for Guava because it supports Java 8), I realized what I was missing. (I did annotate one class like these, `ImmutableMultisetGwtSerializationDependencies`, back in cl/376926723. The plain `GwtSerializationDependencies` classes do not need to be annotated because they are _subclasses_ (which are never used) of the "real" classes, not _superclasses_.) RELNOTES=n/a PiperOrigin-RevId: 708001530
RELNOTES=n/a PiperOrigin-RevId: 708050415
…acing `@ParametersAreNonnullByDefault`. We've annotated individual classes that haven't been annotated for nullness as `@NullUnmarked`. That will likely take precedence over `@ElementTypesAreNonnullByDefault`. Even if it does not, it will take precedence over `@NullMarked`, to which we will be migrating soon. I normally recommend annotating individual classes with `@NullMarked`, rather than packages. However, because Guava supports Java 8, and because users sometimes use reflection to inspect arbitrary annotations on Guava's classed (such as by using Mockito to mock them), there is some [danger](https://github.com/jspecify/jspecify/wiki/version-compatibility#runtime) in annotating individual classes with `@NullMarked`, whose [`@Target` includes `MODULE`](https://jspecify.dev/docs/api/org/jspecify/annotations/NullMarked.html), which isn't available under Java 8. RELNOTES=n/a PiperOrigin-RevId: 708300606
They are redundant with the package-level annotations from cl/708300606. (Again, I recommend against package-level annotations in general, but they're the best option in our specific case because we are likely to have Java 8 users who use Mockito to mock some of our classes.) For our testlib packages, I've left the usages alone: We haven't inserted a package-level annotation in those packages except for in `c.g.c.testing`. (We could pursue doing adding it, but we'd first need to insert class-level annotations in the unannotated classes.) Really, even some of the "annotated" testlib code likely hasn't been fully annotated, but that's a separate problem. Anyway, the problems we're trying to work around with package-level annotations are mostly related to mocking, and we don't expect users to mock our testlib types (which have few users of any kind to begin with). If we hear of problems, we can reevaluate. For now, we'll live with the redundant class-level annotations in `c.g.c.testing`. (Oops, I actually had _removed_ the package-level annotation for `common.testing` in cl/708300606 instead of merely converting it from `ParametersAreNonnullByDefault`. I made that error externally only, and this CL fixes it.) This is the next step toward [using JSpecify in Guava](jspecify/jspecify#239 (comment)). RELNOTES=n/a PiperOrigin-RevId: 708490780
…ault` annotations. This is the next step toward [using JSpecify in Guava](jspecify/jspecify#239 (comment)). At the end of that path, we'll be able to [remove our dependency on JSR-305](#2960) (and on the Checker Framework's annotations), and we'll have one less blocker to [providing a `module-info`](#2970). `@NullMarked` allows tools like kotlinc to produce errors for code like `ImmutableList<String?>`. (Before releasing this change, I'll conduct some further testing to more fully characterize the effects, both under Kotlin 2.1 and prior.) As we make further changes, it will allow kotlinc to detect even more nullness problems. We will make these changes in a series of incremental releases so that users can pick them up gradually, as we did inside Google. In simple cases, users may wish to pick up all the changes at once instead by upgrading straight from Guava 33.4.0 (or an earlier version) to Guava 33.4.4 (or whatever the version to make the final changes ends up being). RELNOTES=Replaced our custom `@ElementTypesAreNonnullByDefault` annotations with the JSpecify `@NullMarked` annotation. PiperOrigin-RevId: 708598410
(i.e., roll back the com.google.common part of cl/377083162) The two should be equivalent, but Kotlin has/had a bug with `<?>` in the context of `@ElementTypesAreNonnullByDefault` (and/or `@ParametersAreNonnullByDefault`?). Now that we're moving away from `@*AreNonnullByDefault` and onto `@NullMarked`, we can use the simpler version. This is the next step toward [using JSpecify in Guava](jspecify/jspecify#239 (comment)). PiperOrigin-RevId: 708605353
…reduce its retention to `CLASS`. We'll continue annotating our APIs with it for now, since it can be helpful for NullAway and perhaps other tools. (But please [let us know](https://github.com/google/guava/issues/new?template=Blank+issue) if you are depending on it from a tool other than NullAway.) This is the next step toward [using JSpecify in Guava](jspecify/jspecify#239 (comment)). Also, I've updated the Javadoc to belatedly note that `ParametricNulless` isn't used by `NullPointerTester` anymore (as of cl/530341970). RELNOTES=Changed `@ParametricNullness` into a no-op for Kotlin and IntelliJ. Before now, it was forcing many usages of type variables to have [platform types](https://kotlinlang.org/docs/java-interop.html#null-safety-and-platform-types), which meant that Kotlin couldn't check those usages for nullness errors. With this change, Kotlin can detect more errors. PiperOrigin-RevId: 708610470
A future step will migrate from these and our already existing usages of the Checker Framework `@Nullable` to the JSpecify `@Nullable`. This is the next step toward [using JSpecify in Guava](jspecify/jspecify#239 (comment)). RELNOTES=Migrated from `@CheckForNull` to Checker Framework `@Nullable`. Most tools recognize both annotations, so we expect this to be a no-op in almost all cases. PiperOrigin-RevId: 708617636
(Or rather, demote it to a test-only dependency for `guava-testlib` only.) Fixes #2960 This is the next step toward [using JSpecify in Guava](jspecify/jspecify#239 (comment)). RELNOTES=n/a PiperOrigin-RevId: 708694414
This is the next step toward [using JSpecify in Guava](jspecify/jspecify#239 (comment)). RELNOTES=Migrated from Checker Framework annotations to JSpecify annotations. PiperOrigin-RevId: 708707163
This is the final(?) step in [using JSpecify in Guava](jspecify/jspecify#239 (comment)). RELNOTES=n/a PiperOrigin-RevId: 708715141
…sing string to Long PiperOrigin-RevId: 710059358
RELNOTES=n/a PiperOrigin-RevId: 710066779
(The duplicate was `state.ca.us` in `SOMEWHERE_UNDER_PS`.) PiperOrigin-RevId: 710078801
This makes our code behave the same for sneaky checked exceptions that occur _when our implementations use reflection_ as for those that occur when our implementations use direct calls. This shouldn't matter for any of the code that I'm migrating to `sneakyThrow` in this CL, but there are other cases in which it could matter, and we're probably best off standardizing on one approach, just as we've done for _catching_ sneaky checked exceptions. Plus, pull each package's `sneakyThrow` out into its own top-level class for reuse. Also, sneak in a few other tiny cleanups: - We don't normally use `@GwtCompatible` in Truth, so remove it from `J2ktIncompatible`. - We can now use `Primitives.wrap` to produce a better error message for `isIntanceOf(primitiveType)`. RELNOTES=n/a PiperOrigin-RevId: 710111747
RELNOTES=n/a PiperOrigin-RevId: 710113358
There are still so many more, but I ran out of steam. Also, in Truth's `Platform` class, migrate off the deprecated `Splitter.onPattern`, and start using the now-non-`@Beta` `splitToList`. PiperOrigin-RevId: 710166260
… references. RELNOTES=n/a PiperOrigin-RevId: 763974446
RELNOTES=n/a PiperOrigin-RevId: 764245786
RELNOTES=n/a PiperOrigin-RevId: 764362778
…rt from the exception type. We are not currently deprecating the method since the differing exception types mean that it may not be trivial to update uses. Fixes #3105. RELNOTES=n/a PiperOrigin-RevId: 766184019
…igration) by using Truth. As noted in the code comment, we may someday encounter *another* Error Prone warning. But at least now we'll be writing the obvious code. PiperOrigin-RevId: 766217089
Bumps the github-actions group with 2 updates: [ossf/scorecard-action](https://github.com/ossf/scorecard-action) and [github/codeql-action](https://github.com/github/codeql-action). Updates `ossf/scorecard-action` from 2.4.1 to 2.4.2 - [Release notes](https://github.com/ossf/scorecard-action/releases) - [Changelog](https://github.com/ossf/scorecard-action/blob/main/RELEASE.md) - [Commits](ossf/scorecard-action@f49aabe...05b42c6) Updates `github/codeql-action` from 3.28.16 to 3.28.18 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@28deaed...ff0a06e) Fixes #7822 RELNOTES=n/a PiperOrigin-RevId: 766643801
RELNOTES=n/a PiperOrigin-RevId: 767108998
(like cl/767108998 but for `false` (which I'm not sure I was aware we ever set explicitly) instead of `true`) RELNOTES=n/a PiperOrigin-RevId: 767189860
- Our App Engine users haven't used the backport in years. - Our use of JDK regex in the open-source release has been [intentional](#3147) for years; it's no longer just an accidental consequence of how we briefly published _only_ the backport externally (around [Guava 20](https://github.com/google/guava/wiki/Release20)). RELNOTES=n/a PiperOrigin-RevId: 767266712
The original OSGi metadata was added back in 53abadc, at which point it mentioned `javax.annotation`. Since then, we've added and removed various annotation dependencies, apparently without ill effects. (And when we tried to make a change that clearly _did_ require a change to the metadata in cl/103098597, we apparently got an error.) So it's possible that listing annotations has _never_ been necessary or at least that it became unnecessary in the 3.5 years between those two prior changes. Or maybe none of our users both use OSGi and try to read our nullness annotations (but if they did, they'd have problems)? Anyway, if listing annotations _is_ important, then we should probably be doing it for the Error Prone and J2ObjC annotations, too.... But for some reason, when I was [replying to an comment that mentioned OSGi on the Jackson issue tracker](FasterXML/jackson-future-ideas#87 (reply in thread)), I decided that it was worth dipping my toes in here, and I guess I figured I'd start small. RELNOTES=Listed the JSpecify annotations as an optional dependency in our OSGi metadata. PiperOrigin-RevId: 768209312
… logic to address crashes observed in J2ObjC client applications. RELNOTES=n/a PiperOrigin-RevId: 768889976
…cker. RELNOTES=n/a PiperOrigin-RevId: 769637569
Quoting myself from cl/768889976: > - Maybe we're currently preventing the `AbstractTransformFuture` in `next` from being deallocated right up until `next = next.next`, at which point it's stored only in `curr`, which isn't enough to keep it alive? And then some combination of the `AbstractTransformFuture`, the `AbstractFuture` that is its input, the `Failure` instance that that `AbstractFuture` holds, and the `Throwable` inside _that_ can start getting deallocated? > - And similarly: `AbstractFuture<?> future`, while it starts out with the value of the parameter, gets [overwritten](https://github.com/google/guava/blob/95e071207526363ffb6c16933b2215f89dea232f/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L781) (in the case of handling `setFuture`) by a value that is referenced from `curr`. But then `curr` goes out of scope before we do things like retrieve the listeners from `future`, so `future` might be deallocated. RELNOTES=n/a PiperOrigin-RevId: 769710082
It isn't all that easy to see that there are 16 zeroes in the current code. I think this alternative is more transparent. (We could also use `BigInteger.ZERO.setBit(64)`.) RELNOTES=n/a PiperOrigin-RevId: 772120376
RELNOTES=n/a PiperOrigin-RevId: 772927807
RELNOTES=n/a PiperOrigin-RevId: 773069181
…nding on it. RELNOTES=n/a PiperOrigin-RevId: 773379664
RELNOTES=n/a PiperOrigin-RevId: 773748954
…epending on it. RELNOTES=n/a PiperOrigin-RevId: 773783391
…j)` failure handling logic. The changes did not resolve crashes observed in J2ObjC client applications. PiperOrigin-RevId: 774775376
RELNOTES=n/a PiperOrigin-RevId: 777831252
RELNOTES=n/a PiperOrigin-RevId: 778018466
RELNOTES=n/a PiperOrigin-RevId: 778055938
Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action). Updates `github/codeql-action` from 3.28.18 to 3.29.2 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@ff0a06e...181d5ee) Fixes #7852 RELNOTES=n/a PiperOrigin-RevId: 778068825
Relevant to #2861, but it's a step in the opposite direction (by not having a class for this at all, let alone a public one). (Alternatively: One reason not to provide a public `ImmutableEntry` type was that the current `ImmutableEntry` permits null values, which our other `Immutable*` types do not. From that perspective, this CL is a potential step _toward_ a public `ImmutableEntry` class, since it would allow us to reclaim the class name but with different behavior. But I wouldn't recommend holding your breath.) Note that we already have an `ImmutableMapEntry` class ("an immutable `Map.Entry` for an `ImmutableMap`"), so it's nice to be rid of `ImmutableEntry` ("an immutable `Map.Entry` for any purpose). RELNOTES=n/a PiperOrigin-RevId: 778196681
RELNOTES=n/a PiperOrigin-RevId: 778212052
Since members of `@GwtCompatible` classes are assumed to be GWT-compatible by default, there is no need for the annotation except on classes. Arguably, it's not necessary even on public nested classes, since those have annotations on their enclosing classes. But there is value in having the annotation in the generated Javadoc for the class itself, so I've kept the occurrences that I've seen. (There was one on [`FutureCombiner`](https://guava.dev/FutureCombiner), at least. I rather doubt that we're being consistent about including it on all such types, though.) Most (all?) such existing annotations on methods are left over from when we were saying something meaningful, `@GwtCompatible(serializable = ...)`. If I'd been fully on the ball, I would have removed them back in cl/767108998 and cl/767189860. Along the way, I also noticed a couple static imports of members of the current class. I think I removed them all (just `Maps` and `Helpers`). RELNOTES=n/a PiperOrigin-RevId: 778311761
RELNOTES=n/a PiperOrigin-RevId: 778480079
This _would_ prepare for adding `@InlineMe` except that I don't expect that to work well when both the "before" and "after" try to import a class named "`Objects`." Still, this change at least establishes the a migration from our methods to the JDK's is safe. RELNOTES=n/a PiperOrigin-RevId: 778491389
I can't remember offhand if I wanted that support before. Maybe? But it became possible way back in mojohaus/animal-sniffer#212. I guess this qualifies as the "nightmare scenario" for having our own versions of the annotation (#3649, #3652) :) It hardly matters. RELNOTES=n/a PiperOrigin-RevId: 778575641
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 : )