cpovirk

Address some more counterfactual [CheckedExceptionNotThrown](https://errorprone.info/bugpattern/CheckedExceptionNotThrown) findings. I suspect that IntelliJ flags most of these, especially since its analyses seem happy to treat Guava as a "closed world" with no callers/overrides outside the project, if I'm remembering right. Anyway, that makes them nice to fix so that F2 doesn't jump to them. We don't normally worry much about a stray `throws Exception` on a `test*` method in particular, but it was easier to have the tooling remove them (and then glance over the results) than to make it smarter, and it's a nice bonus to remove such `throws` clauses, anyway. It's possible that I could rerun this cleanup until I reach a fixed point, since each removal may unlock removals downstream. I think that I made one follow-up change somewhere in `util.concurrent`. Maybe I'll do another "full" round, maybe using IntelliJ in case it catches anything that Error Prone did not. I made no effort to look at `abstract` methods that might have no implementations that actually throw a declared exception. I made no effort to remove calls to `super.setUp`/`tearDown` when those calls are no-ops (because they call the methods on plain `TestCase`). If I were to do so, that might unlock more `throws` removals on the `setUp` and `tearDown` methods that are making those calls. There were some cases that I had to revert: - `TypeTokenTest.CannotConstruct` constructor - `AbstractIdleService`: `DefaultService` and `TestService`, both `startUp` and `shutDown` (though I may or may not have needed to revert all four) - `AbstractExecutionThreadServiceTest.FakeServices.startUp` Finally, I made `ListeningExecutorServiceTest.FakeExecutorService` `final` while I was in the area. RELNOTES=n/a PiperOrigin-RevId: 938063962

Remove caching of cheap collection views across `common.collect`. (like https://github.com/google/guava/commit/e87d019e47a29bf263a82fe81caede34e9728e15 and https://github.com/google/guava/commit/0a8e1ec55afe1d9361ebbd0c4149adfbb32ccf9a but for a wider variety of collections) This includes removing `ViewCachingAbstractMap` entirely in favor of using `AbstractMap` directly. For J2ObjC safety, I removed `@Weak` and `@WeakOuter` annotations now that there is no reference cycle between the outer collection and its view collections. (Really, we should have used `@RetainedWith` instead of `@Weak*`, anyway, so this CL improves fixes existing issues in addition to perhaps preventing new ones. For more on `@RetainedWith`, see cl/781580713.) Parts of the `@Weak*` changes should have been done as part of https://github.com/google/guava/commit/0a8e1ec55afe1d9361ebbd0c4149adfbb32ccf9a for `Compact*HashMap`. _Not_ covered in this CL: - various other cached views that might benefit, such as `RegularImmutableSet.asList` (cl/922882558) - views that I worry at least a little more about, mainly "invertible operations" (`BiMap.inverse`, `NavigableSet.descendingSet`, etc.) - maybe migrating off `AbstractMap` in some additional cases in which it would make sense to avoid inheriting its fields - GWT/J2CL RELNOTES=n/a PiperOrigin-RevId: 973885682

Standardize racy lazy init. This addresses almost all our https://errorprone.info/bugpattern/AssignmentExpression warnings. The final(?) warnings will be addressed by cl/959862978. RELNOTES=n/a PiperOrigin-RevId: 962152630

Address various findings, mostly from IntelliJ. Most of the findings are around Javadoc links to non-visible APIs. The mildly annoying case is when we write something like `{@link #keySet}`: If we were building Javadoc with the `-private` flag, then these references would be to the private field of that name. And that's... probably fine, since the rendered Javadoc is in fact going to include private members? But I guess it's questionable to refer to private members of another class at all, even from within Javadoc? Anyway, when we run plain old Javadoc, the links get resolved to `keySet()`, as desired. So the changes of that nature are about making IntelliJ happy (so that I can jump from "real error" to "real error" more easily in cl/934353699) and maybe being slightly more principled about things, rather than fixing errors in our rendered Javadoc. (Also notice that plenty of the findings were in `javatests`, which we don't normally generate Javadoc for.) A couple other notes on Javadoc: - I stopped trying to link to `EmptyImmutableTable`, which was deleted in cl/43207266. There may well have been some other deletions (or at least moves, like `hashFloodingDetected`, mentioned in `ImmutableSetHashFloodingDetectionBenchmark`) that I didn't dig into or at least didn't save notes on. - I made the Android flavor of `TopKSelector` refer to `Comparators.least`, eliminating a diff from the mainline, since we added `least` to the Android flavor a while back. The other notable class of findings is unnecessary casts. RELNOTES=n/a PiperOrigin-RevId: 934979370

Enable translation of actual visibility modifiers in `com.google.common` (excluding Truth). For `protected` methods which are not accessible elsewhere in the package/module under Kotlin, declare a bridge `internal` method, and updates call sites to use it instead. (It's possible that I've made updates in some places that weren't strictly necessary.) RELNOTES=n/a PiperOrigin-RevId: 937492418

Enable translation of actual visibility modifiers in `com.google.common` (excluding Truth). For `protected` methods which are not accessible elsewhere in the package/module under Kotlin, declare a bridge `internal` method, and updates call sites to use it instead. (It's possible that I've made updates in some places that weren't strictly necessary.) RELNOTES=n/a PiperOrigin-RevId: 936234321

More aggressively throw `NullPointerException` in `common.graph`. Currently, we sometimes throw `IllegalArgumentException` and/or throw later (if at all). This was hidden because `PackageSanityTest` was exiting as soon as it hit the first failure. (It exited successfully, assuming that the first failure matched what we expect.) This CL exists because that `PackageSanityTest` setup was fragile to the relative ordering of the prod and test jars on the classpath: IIUC, we were seeing the prod jar first, and that was triggering the expected failure, but later we started seeing the test jar first, so we started seeing failures related to `TestUtil`. I fixed the failures in `TestUtil` by adding `@Nullable` to some parameters there. (I could reasonably also just have excluded `TestUtil` from `PackageSanityTest` entirely, since we're almost entirely interested in testing our _prod_ code. Or I could have added `checkNotNull`, but that would arguably have been a tiny regression in the extremely unlikely event that a caller were to pass `null`.) That might have been enough to prevent the test failure in practice, but the setup was still fragile. So I configured sorting of classes across jars (cl/948465826), and I'm removing the short-circuiting behavior (this CL). That requires fixing the resulting "latent" failures. That brings us back to the main part of this CL, which is to perform null checks eagerly, as the newly comprehensive `NullPointerTest` testing requires—and as is at least arguably a good idea, anyway, since it's closer to the behavior seen today by Kotlin users and maybe closer to some future Valhalla behavior. RELNOTES=n/a PiperOrigin-RevId: 949022628

Add some more `@Nullable` annotations, mostly in null-unmarked code. Compare https://github.com/google/guava/commit/4c4b7547bc9f8da93a3e10d84417feb606d566cb and https://github.com/google/guava/commit/f42aa699a9e63c0e42045b738143bf9c470fe3ee. RELNOTES=n/a PiperOrigin-RevId: 947342855

Address places where [CheckedExceptionNotThrown](https://errorprone.info/bugpattern/CheckedExceptionNotThrown) *would* produce warnings if it were to operate on test code. I acknowledge that we are removing a checked exception from `EscaperAsserts.assertBasic`. This could lead to source incompatibilities. For a `guava-testlib` API whose only callers inside Google are in Guava itself, I don't worry about fallout from that. RELNOTES=n/a PiperOrigin-RevId: 937536463

Use yet more `assertThrows` (and a tiny bit more Truth). AssertThrowsMinimizer might again not be happy (though, surprisingly enough, I haven't seen it yet). If so, that is a problem for another day. RELNOTES=n/a PiperOrigin-RevId: 938810532