cpovirk

Remove unnecessary type arguments. This CL comes courtesy of IntelliJ. (I did revert a few files that ended up with errors, probably often from non-javac tools like our transpilers, and I reverted one tiny part of `OrderingTest`. I may have been able to get away with reverting less.) (previously: https://github.com/google/guava/commit/cb0e7e0cb1c62012934d998ca4d0222a758a9831, https://github.com/google/guava/commit/c1ffb313fd084c865e539c9b6dc795edade21d6a, https://github.com/google/guava/commit/35a4ccbcbb86952f1c021424acd70c7526e8964d, https://github.com/google/guava/commit/08f213923dab324b53a5ee93151a2a2c04be0784, https://github.com/google/guava/commit/274062cdc2a3819ff4b0286e57973b1bbe8c8519, which together explain why I'm not seeing hits in the prod code for packages like `collect`) RELNOTES=n/a PiperOrigin-RevId: 906444162

Use `assertThrows` more. I addressed the resulting https://errorprone.info/bugpattern/AssertThrowsMinimizer warnings where I saw them in an early snapshot. But I seem to be seeing them at different places at different times, so I'm leaving some that I'll get in a future round. Also, add two missing(?) tests of `clear()` in backport copy of `MapsTest.ensureNotDirectlyModifiable`. RELNOTES=n/a PiperOrigin-RevId: 895922607

Use Truth in place of `assertEquals` assertions for `Enum` types. RELNOTES=n/a PiperOrigin-RevId: 899198656

Use `assertThat(...).isEqualTo(...)` instead of `assertEquals(..., ...)` for `String` assertions. ...in `base`. RELNOTES=n/a PiperOrigin-RevId: 882875041

Statically import members of `Funnels` and `Hashing`. ...except for `Funnels.asOutputStream`. RELNOTES=n/a PiperOrigin-RevId: 886295873

Address nullness-checking errors in tests. RELNOTES=n/a PiperOrigin-RevId: 884464459

Use Truth in `IntMathTest` and `LongMathTest`. Fix an expected-actual mixup in `LongMath.testPow`. (Thanks, Gemini!) Suppress some false-positive warnings about seeming expected-actual mixups. PiperOrigin-RevId: 901341514

Make `ClosingFuture` use `PhantomReference` instead of `finalize()`. Compare what https://github.com/google/guava/commit/7c6b17c0199c875ffa426c0fb0f51ba7d66f98ec did for `FileBackedOutputStream`. As in that CL, this CL adds `reachabilityFence` calls. I think that the calls are technically more necessary here than they were in `FileBackedOutputStream`, where we could probably [rely on `synchronized` to keep the object alive](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ref/Reference.html#reachabilityFence(java.lang.Object)). Incidentally, they are equally necessary under the current `ClosingFuture` approach that uses `finalize()`. (So that gives some indication of how much they matter _in practice_: probably not much.) I had a thought at one point that maybe `reachabilityFence` was necessary only in the _terminal_ operations: Since every `ClosingFuture` pipeline should end with a terminal operation, we should be able to rely on a `reachabilityFence` in that terminal operation to keep the chain alive. However, I now think it's best to put a fence in all operations: - It's simpler. - It behaves better for broken code that lacks a terminal operation: If not for fences on intermediate operations, then such code might see its `ClosingFuture` closed by GC while it's still operating on it. And while such code is buggy, I don't think we want to cause its intermediate operations to _throw_. By putting `reachabilityFence` calls in such operations, we keep the `ClosingFuture` alive until those operations complete, at which point it can leak "properly," getting closed with no harm to anyone except the resulting log message. Finally: As a minor follow-up to https://github.com/google/guava/commit/9744861cb9b985bb832b81da91233b423b812276, I arranged for the `Finalizer` thread to always have an unobfuscated _thread name_, even when the class name of `Finalizer` gets obfuscated. RELNOTES=Migrated some prod classes from `finalize()` to `PhantomReference` in preparation for [the removal of finalization](https://openjdk.org/jeps/421). (7c6b17c) PiperOrigin-RevId: 881753103

Address some https://errorprone.info/bugpattern/ReferenceEquality warnings. There are many others left, but this is a start. Plus, sneak in a migration to `SimpleImmutableEntry`, which we had avoided long ago for GWT reasons. RELNOTES=n/a PiperOrigin-RevId: 922103048

Use some collection constructors (and a few more static imports). And address some other warnings and oddities. RELNOTES=n/a PiperOrigin-RevId: 909294379

Avoid static importing `BigInteger.valueOf`, remove JUnit parameter comments, and suppress more warnings. (followup to https://github.com/google/guava/commit/68817392f6bcf95394ee2b9a054361f1f57d48d9) RELNOTES=n/a PiperOrigin-RevId: 900888508

Inside `Foo`, refer to "`bar()`" instead of to "`Foo.bar()`." Also, in `ImmutableSortedMap`, belatedly remove a stale comment about explicit type arguments that were added in https://github.com/google/guava/commit/8a1c90e7b34765d720b3711d4180526dde24c124 and removed in https://github.com/google/guava/commit/c1ffb313fd084c865e539c9b6dc795edade21d6a. Apparently the javac flakiness has not returned. I wouldn't be surprised if it were to do so later, but we should have either the type arguments and the comment or else neither. Finally, remove an unnecessary type argument in `ImmutableMultiset` in the backport. RELNOTES=n/a PiperOrigin-RevId: 907153931

Run more tests under J2KT/Native. I also cleaned up `ListenableFutureTester` a little, including making its users actually call `tearDown` (oops). And I eliminated another helper from `JSR166TestCase` in favor of a new, simpler version in `MoreExecutorsTest`. Then, as a bonus, I fixed a http://errorprone.info/bugpattern/JUnitMethodInvoked warning in `ExecutionListTest`. PiperOrigin-RevId: 909884313

Suppress errors from newly enabled nullness checking in more tests, and annotate more tests to reflect which environments they're run under. RELNOTES=n/a PiperOrigin-RevId: 879906051

Use `EqualsTester` more. Plus, fix a few warnings, and deal with a few sketchy tests: - `InvalidatableSetTest` has used `isEqualTo` to test `equals` since its creation in https://github.com/google/guava/commit/d812e15c120fea9c7cf9cd33be21c9cd0e424f81, but that's [the wrong way to do it](https://github.com/google/truth/issues/268), in part because `isEqualTo` has a `==` fast path, which prevents Truth from even calling `equals`. Error Prone had caught this in the original CL, but we suppressed it! Then Gemini fixed the problem without my even having noticed beforehand. - `ImmutableSortedSetTest` had all kinds of things going on: - Way back in cl/7089521, we added `testEquals_bothExplicitOrdering`. But contrary to its name, it does not use an explicit ordering for _both_ sets, only for the "other" (i.e., non-`ImmutableSortedSet`) set. I renamed the test to reflect that only _one_ set is using an explicit ordering. - Also, "explicit" became a misleading term when we later renamed `Comparators.givenOrder` to "`Ordering.explicit`." I picked a new name that avoided that association, too. - Almost as way back in cl/16428259, we added `testEquals_bothExplicitOrdering_StringVsInt`. But contrary to its name, it does not use an explicit ordering for _either_ set. I changed it to use an explicit ordering for the "other" set. - (Really, testing equality on collections with different equivalence relations is itself a sketchy thing to do. While the JDK developers have discussed defining a correct behavior for such cases (at least in part to address [JDK-6394757](https://bugs.openjdk.org/browse/JDK-6394757)), that hasn't happened, and I have reservations. I could see removing such comparisons from our tests entirely, especially if the logical alternative is to go all-in on testing them.) - But actually, I ended up merging some tests because `EqualsTester` does a lot for us. - But my initial attempt at merging caused problems: `EqualsTester` did _so much_ for us that it started calling `treeSetOfStrings.equals(hashSetOfIntegers)`, which triggered the GWT/J2CL `ClassCastException` discussed in `assertNotEqualLenient`. Since all that we really want is to test the behavior of `ImmutableSortedSet.equals(<<various things>>)`, I put all the mismatched-type assertions into separate methods, and I made exactly the desired `equals` calls directly, rather than letting `EqualsTester` make even more or `isNotEqualTo` _hopefully_ (similar to the `isEqualTo` discussion earlier) make the `equals` call that we want. - Also, my initial `Comparator` changes used a discouraged, Google-internal overload of `Sets.newTreeSet`, so I copied that overload into the test and gave it what I hope is a clearer name. I also migrated off `newTreeSet` elsewhere in the file. - I also eliminated the calls to `assertNotEqualLenient` entirely: They were effectively tests of `TreeSet.equals`, not of `ImmutableSortedSet.equals`. (The direct calls to `equals` then let http://errorprone.info/bugpattern/EqualsIncompatibleType do its thing, so I suppressed.) - And I think I may have expanded `equals` test coverage a little bit, notably to check how we handle type mismatches that produce `ClassCastException` when we _don't_ trigger [the `SortedSet` fast path](https://github.com/google/guava/blob/e716c22aaf51d6f5a9a66140f1623fe132e58d56/guava/src/com/google/common/collect/RegularImmutableSortedSet.java#L186). RELNOTES=n/a PiperOrigin-RevId: 894225096

Prepare for initial J2KT support in `common.hash`. ...which is coming in cl/899584452. This includes: - Add lots of `@J2ktIncompatible` annotations. - Add a missing `@Nullable` annotation to `ExpectedHashCode.asLong` in `HashCodeTest`. Bonus: Migrate off deprecated `Hashing.sha1` in `HashCodeTest`, which doesn't actually care about which specific hash function it uses. (OK, in `testPadToLongWith1Byte`, it cares that it has a hash function with a very short output, so it uses `crc8`.) RELNOTES=n/a PiperOrigin-RevId: 901327552

Modernize a few tests, including migrating off Mockito (to improve cross-platform compatibility) and also onto Truth and `assertThrows`. RELNOTES=n/a PiperOrigin-RevId: 918097212

Lambdafy some packages, mostly tests. Compare cl/884639316. RELNOTES=n/a PiperOrigin-RevId: 885150741

Lambdafy some packages, mostly tests. Compare cl/884639316. RELNOTES=n/a PiperOrigin-RevId: 885687637

Lambdafy some test packages. Compare cl/884639316. RELNOTES=n/a PiperOrigin-RevId: 885055193