Then, where appropriate, make them `private`, or even inline them.
(I guess that I've set aside my "Why even write '`private`' in a test class at all?" perspective, at least for the moment :))
RELNOTES=n/a
PiperOrigin-RevId: 1008110306
(prompted by a review comment in https://github.com/google/guava/commit/37535d73f0416f30e0301efe61a8eb8ede44c1b7)
We should easily make this available publicly, but we've had reservations around our `Forwarding*` classes in general (b/5231423), so I'm reluctant to expose more there without further thought.
RELNOTES=n/a
PiperOrigin-RevId: 1008047203
`rotate(array, distance, fromIndex, toIndex)` computed `length` and `-distance % length` without guarding an empty range, so a call with `fromIndex == toIndex` threw `ArithmeticException`. Return early when the range has fewer than two elements.
Fixes https://github.com/google/guava/pull/8772
Fixes https://github.com/google/guava/pull/8774
RELNOTES=`primitives`: Fixed `ArithmeticException` when calling `rotate` on an empty subrange of a multi-element array.
PiperOrigin-RevId: 1006325060
- More clearly document that `StandardElementSet` is the class that we're testing _and_ where the list of legal methods is documented.
- Make methods throw by default (by virtue of calling `delegate()`), tightening the restrictions on which methods can be called.
(further evidence for https://github.com/google/guava/issues/1575)
RELNOTES=n/a
PiperOrigin-RevId: 1005714075
Currently:
- `AbstractBiMap` runs `replaceAll` on its forward map first, so if that throws in the middle, its inverse is never updated. (Additionally, if it detects a value conflict while populating the inverse later, it likewise ends up in an inconsistent state.)
- `HashBiMap` clears itself at the beginning, so if it throws in the middle, it ends up missing entries.
Fixes https://github.com/google/guava/pull/8766 (by arshsmith), which proposed a fix for the specific case of `filterValues`.
RELNOTES=n/a
PiperOrigin-RevId: 1004886559
`ClassInfo.isTopLevel()` (and so `ClassPath.getTopLevelClasses()`) assumed that any `$` in a class name marks a nested class, so generated top-level classes like `$AutoValue_Foo` were silently dropped. `getSimpleName()` had the same problem, returning `AutoValue_Foo`.
_Consecutive_ `$` characters generally appear in runtime-generated classes, in which case they are outside the domain of `ClassPath`. However, they can appear at compile time, too, such as in desugared Android code—though, in the specific example of Android, `ClassPath` may well not work anyway. In any case, such classes don't represent true nested classes.
This new logic is all still based on heuristics, but it handles the common cases of generated class names.
Fixes https://github.com/google/guava/pull/8740
Fixes https://github.com/google/guava/issues/3349 well enough in practice.
RELNOTES=n/a
PiperOrigin-RevId: 1004273644
`decodingStream` methods to synchronize their methods as typical of
`InputStream` and `OutputStream` implementations.
RELNOTES=n/a
PiperOrigin-RevId: 1004050756
`Double.MIN_VALUE` and `Float.MIN_VALUE` represent the smallest positive nonzero values (`2^-1074` and `2^-149`) rather than the most negative finite values, unlike `Integer.MIN_VALUE` and `Long.MIN_VALUE`.
RELNOTES=`primitives`: Added `Doubles.MIN_POSITIVE_VALUE` and `Floats.MIN_POSITIVE_VALUE` as more clearly named aliases for `Double.MIN_VALUE` and `Float.MIN_VALUE`.
PiperOrigin-RevId: 1004024484
`FilteredEntryMap.EntrySet` wrapped only the entries returned by `iterator()`, so the entries returned by `toArray()` were the backing map's own entries, and their `setValue` bypassed the filter.
The fix is to override `toArray`. But instead of using `standardToArray` like `AbstractBiMap.EntrySet` and `UnmodifiableEntries` do, we use `newArrayList(iterator()).toArray(...)` like `FilteredMapValues` and `FilteredEntryMap.KeySet` do so that we avoid evaluating the predicate against all elements twice (once in `size()` and once in `iterator()`).
- Fixes https://github.com/google/guava/pull/8758
- Support for https://github.com/google/guava/issues/1575
RELNOTES=n/a
PiperOrigin-RevId: 1003049749
`ThreadFactory.newThread` is permitted to return `null` to reject a request to create a thread. Previously, a factory built by `ThreadFactoryBuilder` threw `NullPointerException` if its backing factory returned `null`.
Fixes https://github.com/google/guava/issues/3568.
Closes https://github.com/google/guava/pull/8742.
RELNOTES=In the `ThreadFactory` returned by `ThreadFactoryBuilder`, a null return from `newThread` on the backing `ThreadFactory` is now propagated to the caller. Previously it triggered a NullPointerException.
PiperOrigin-RevId: 1001877586
_If_ `java.io.tmpdir` is world-writable and does not set the very important sticky bit, then an attacker has a chance to unlink the temp file and replace it with a symlink between when it is created and when it is opened. This could cause the user of the stream to write/read data to/from an unintended location.
It's not clear that it's worth defending against this, given that the problem arises only with broken temp-directory permissions, which are much more likely to open holes elsewhere than here. But given the rise of security scanning over time, I'm figuring that it's worth addressing even _some_ borderline reports (like this one from our internal scans) when it appears straightfoward and safe enough to do so.
RELNOTES=n/a
PiperOrigin-RevId: 1001464603
inconsistent with concurrent updates.
`SimpleStatsCounter` is documented as thread-safe, but it updates its counters independently
and without locking, so a snapshot taken during an update can include part of it (for example,
a load-success count without the corresponding load time). That's intentional for performance,
so document it rather than adding synchronization.
Fixes https://github.com/google/guava/pull/8741
RELNOTES=n/a
PiperOrigin-RevId: 999541957
This prevents (for the case of `GcFinalization`, but other cases are similar):
- a `NullPointerException` if our finalization logic runs before `FinalizableReference` has assigned to `this.latch`
- indefinite retention of the `Reference` object if our finalization logic runs before `reference.add`
Fixes https://github.com/google/guava/issues/8738
RELNOTES=n/a
PiperOrigin-RevId: 998855369
- While it makes sense to have an HTML `<title>` (i.e., what shows up in the tab button or taskbar button for that page) that says (e.g.) "Truth API," it's weirder for the in-page title to say "Truth API" instead of just "Truth." Javadoc lets us set the two independently; I just chose poorly in https://github.com/google/guava/commit/49300093df01df7d7bea5f1d657ecf58fbc4f596.
- Truth was showing a copyright date of 1980, presumably some kind of default from somewhere or other. I've given it [the same value as Guava](https://github.com/google/guava/blob/1da08c4d381abf3613ad956d3aec9fa77dfc94b2/pom.xml#L100).
It's possible that [JSpecify](https://github.com/jspecify/jspecify/issues/904) would have the same issue, though I'm not sure because it uses Gradle instead of Maven. But even if it does, I'm not sure that its Javadoc ends up with a summary page at the moment, I guess because it contains only one package? So maybe there's nowhere for "JSpecify API" to appear in the actual page text, only in the `<title>` where we want it.
RELNOTES=n/a
PiperOrigin-RevId: 996717116
But (for better or for worse) preserve the existing lenient behavior of `setCount(element, 0, 0)`.
Fixes https://github.com/google/guava/pull/8720
RELNOTES=n/a
PiperOrigin-RevId: 995897499
The config from https://github.com/google/guava/commit/c05d28807a6f0fbcb0379349884632c07180a4bd is not working how I'd hoped: We're getting PRs to [bump deps like `org.codehaus.mojo:animal-sniffer-maven-plugin`](https://github.com/google/guava/pull/8725), not only PRs for Maven and Maven Wrapper. It's possible that we should just give in and accept those, too, but I was hoping to defer that.
I'm not confident that this new config will work, either!
RELNOTES=n/a
PiperOrigin-RevId: 995193422
We still won't be able to approve these and have them automatically imported. But at least we'll get PRs that I can import manually, as I do currently for GitHub Actions.
RELNOTES=n/a
PiperOrigin-RevId: 995053987
Fixes https://github.com/google/guava/issues/8715.
RELNOTES=We now recommend `HashMap.newHashMap` instead of `Maps.newHashMapWithExpectedSize`, etc.
PiperOrigin-RevId: 994725599
And document why we can't use `ConcurrentHashMap.newKeySet` here.
The bogus `extends @Nullable Object` isn't detected by our nullness checking because our J2CL builds don't use `@NullMarked` classes for `java.*`.
RELNOTES=n/a
PiperOrigin-RevId: 994652789
`LimitedInputStream.skip` passed a negative count on to the delegate. `FileInputStream` then seeks backward and returns a negative value, which was subtracted from the bytes left, so the stream could move before the position where the limit began and supply more than the limit.
Fixes https://github.com/google/guava/pull/8712
RELNOTES=n/a
PiperOrigin-RevId: 994451753
Yes, one of these is changing the "old implementation" in a benchmark. That could in theory affect performance, but it seems extremely unlikely to. And if somehow it does, it seems only fair to compare against this improved implementation, anyway. (My change makes that code look at lot like the code in `NewExecutionListWithoutReverse` and in the prod `ExecutionList` itself.)
RELNOTES=n/a
PiperOrigin-RevId: 989830275
cpovirk