Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pull] master from google:master #247

Open
wants to merge 1,189 commits into
base: master
Choose a base branch
from
Open

[pull] master from google:master #247

wants to merge 1,189 commits into from

Conversation

pull[bot]
Copy link

@pull pull bot commented Apr 26, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

@pull pull bot added the ⤵️ pull label Apr 26, 2021
cpovirk and others added 29 commits April 23, 2024 18:41
Bumps [actions/checkout](https://github.com/actions/checkout) from 4.1.3 to 4.1.4.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@1d96c77...0ad4b8f)

Fixes #7182

RELNOTES=n/a
PiperOrigin-RevId: 627815729
…rsion of our nullness checker.

RELNOTES=n/a
PiperOrigin-RevId: 627817079
Fixes #7185

RELNOTES=n/a
PiperOrigin-RevId: 628393483
RELNOTES=n/a
PiperOrigin-RevId: 628429745
RELNOTES=n/a
PiperOrigin-RevId: 628450178
… a rare code path.

When the `Builder` entries length does not match the `size` and `orderEntriesByValue` is used in combination with `buildKeepingLast` and there are no duplicate keys, then the size used for sorting incorrectly becomes the length of the entries array instead of the size tracked by the `Builder`. This can lead to the `sort` method trying to access null entries from the array.

RELNOTES=`collect`: Fixed a potential `NullPointerException` in `ImmutableMap.Builder` on a rare code path.
PiperOrigin-RevId: 629407343
I messed up the benchmarks, so there's a chance that cl/626542813 actually made things worse. The impact is probably still small, and it's hard to actually tell what will work better in practice. But this is largely an educational experience for me, so it continues....

RELNOTES=n/a
PiperOrigin-RevId: 629480444
(for example, `ImmutableList.toImmutableList()`)

For now, we're making them `@Beta` just in case users encounter enough problems that we find it less disruptive to revert this change than to keep it. However, we plan to remove `@Beta` soon, at which point we'll be committed to this APIs. If you use Guava under Android, please [test with Guava 33.0.0 or higher](https://groups.google.com/g/guava-announce/c/9-dw_C6G_NM), ideally with 34.0.0 or higher (which will contain this commit), and [report any problems](https://github.com/google/guava/issues/new?assignees=&labels=type%3Ddefect&projects=&template=bug_report.yaml).

Our expectation is that this commit should not cause problems, even for users who don't use enable [library desugaring](https://developer.android.com/studio/write/java11-default-support-table). But we will see what happens in wild.

Of course, if you want to actually _use_ these APIs, then you'll need to [enable library desugaring](https://developer.android.com/studio/write/java8-support#library-desugaring) or target a [new enough version of Android](https://developer.android.com/reference/java/util/stream/Stream), just as with any other `Stream`-based APIs.

(progress toward #6567)

RELNOTES=`collect`: Made our `Collector` APIs (e.g., `ImmutableList.toImmutableList()`) available in `guava-android`.
PiperOrigin-RevId: 629491350
RELNOTES=n/a
PiperOrigin-RevId: 629786924
(I'll probably just roll all my attempts back.)

We got reports of a regression in Bazel.

PiperOrigin-RevId: 630366325
The overall impact of my optimization attempts is unclear, so I'm going to put us back in the state we were in 6 months ago: That old implementation used slightly more memory than the later ones, and it can't be any faster now than it was then, but at least we know that it won't be any slower.

PiperOrigin-RevId: 630380173
But at least keep part of the change that moved from an anonymous class to a named class, since that maybe justifies one tenth of the time that I've forced people to spend on this....

RELNOTES=n/a
PiperOrigin-RevId: 630387250
…RangeMap`.

RELNOTES=n/a
PiperOrigin-RevId: 630655296
[`AutoCloseable`](https://developer.android.com/reference/java/lang/AutoCloseable) was added in API Level 19, so we can rely on it.

RELNOTES=n/a
PiperOrigin-RevId: 631389672
It was [added in API Level 19](https://developer.android.com/reference/java/lang/Throwable#addSuppressed(java.lang.Throwable)), so we can rely on it.

Also, address an `IdentityHashMapUsage` warning, and migrate off `newIdentityHashMap`.

RELNOTES=n/a
PiperOrigin-RevId: 631389682
It was [added in API Level 19](https://developer.android.com/reference/java/lang/Throwable#addSuppressed(java.lang.Throwable)), so we can rely on it.

We could do further work to migrate our own code (e.g., `ByteSource`) off `Closer` entirely. I'll leave that for the future.

RELNOTES=n/a
PiperOrigin-RevId: 631431407
Bumps [actions/checkout](https://github.com/actions/checkout) from 4.1.4 to 4.1.5.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@0ad4b8f...44c2b7a)

Fixes #7205

RELNOTES=n/a
PiperOrigin-RevId: 631497879
This increases the chances that they will be sorted from fewest args to most args.

It also matches what we already do for the `of` methods of key-value collections like `ImmutableMap`.

RELNOTES=n/a
PiperOrigin-RevId: 631629370
It's been used for size-zero maps for years.

RELNOTES=n/a
PiperOrigin-RevId: 632659530
…doesn't rely on other unsupported classes.

RELNOTES=n/a
PiperOrigin-RevId: 633880474
PiperOrigin-RevId: 633909149
RELNOTES=n/a
PiperOrigin-RevId: 634384683
…testing.

We had disabled the tests in that environment because `NullPointerTester` performed reflection on types that contained `Collector`-based APIs. Since `Collector` wasn't available, the tests failed. But now, we've enabled library desugaring for our internal tests (though we continue not to _require_ library desugaring unless users actually use such APIs), so the tests can work again.

(relevant to #6567)

RELNOTES=n/a
PiperOrigin-RevId: 634784425
cpovirk and others added 30 commits October 31, 2024 09:07
RELNOTES=`io`: Exposed some additional Java 8 APIs to Android users.
PiperOrigin-RevId: 691823401
Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action).

Updates `github/codeql-action` from 3.27.0 to 3.27.1
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@6624720...4f3212b)

Fixes #7508

RELNOTES=n/a
PiperOrigin-RevId: 695443346
RELNOTES=Optimize SetView.immutableCopy
PiperOrigin-RevId: 695486652
…ent validation.

...and blame it on Java :)

We'd gotten this right for the lesser-used `isUriInetAddress` and `forUriString` but not for these more commonly used methods.

See #2587 (comment)

RELNOTES=n/a
PiperOrigin-RevId: 696253161
…ression.

(followup to cl/691799318)

RELNOTES=n/a
PiperOrigin-RevId: 696673247
I notice a few more `try`-`fail` tests that should use `assertThrows` but were missed by our automation for whatever reason....

PiperOrigin-RevId: 696930033
RELNOTES=n/a
PiperOrigin-RevId: 696954874
(Compare cl/696632561 for Truth. I verified that the Truth change worked in post-submit CI, and (as you'll see) I did some work to verify that this Guava change works in local testing.)

This CL addresses the "linking" part of #6790 but not the "inheriting" part.

I was having trouble getting this to work with the JDK in the `<linkoffline>` section, so I moved it to the `<link>` section. (But not before first accidentally creating a _second_ `<link>` section, which Maven seems to have chosen to ignore without error. See also my other complaints in a comment in the actual `pom.xml`.) Fortunately, we don't need to use `<linkoffline>` for the JDK anymore because we no longer need to have the JDK in the same section as JSR-305 now that `javax.annotation` isn't part of the JDK anymore (and thus there's no longer a conflict about whether the JDK or JSR-305 gets to "claim" it and thus there's no need to resolve it through ordering, which we can control only within sections, not across sections).

Somewhere in the course of working through that, I upgraded `maven-javadoc-plugin` to 3.11.1. That may or may not have turned out to be necessary, but it's probably more likely to help than to hurt.

RELNOTES=n/a
PiperOrigin-RevId: 696975523
Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action).

Updates `github/codeql-action` from 3.27.1 to 3.27.4
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@4f3212b...ea9e4e3)

Fixes #7517

RELNOTES=n/a
PiperOrigin-RevId: 697652635
So does Guava :)

Also, restore balance to the force after cl/696692285 by using `@link` instead of `@code` (or eliminating `#` while keeping `@code`) in various places.

RELNOTES=n/a
PiperOrigin-RevId: 698378812
…ructor.

RELNOTES=n/a
PiperOrigin-RevId: 698442998
RELNOTES=n/a
PiperOrigin-RevId: 698540905
…method from cl/682878547.

RELNOTES=n/a
PiperOrigin-RevId: 698541136
RELNOTES=`base: Deprecated `Charsets` constants in favor of `StandardCharsets`.
PiperOrigin-RevId: 699971004
Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action).

Updates `github/codeql-action` from 3.27.4 to 3.27.5
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@ea9e4e3...f09c1c0)

Fixes #7528

RELNOTES=n/a
PiperOrigin-RevId: 700070591
…FLOW`.

Fixes google/jimfs#383

In Guava, resolve a https://errorprone.info/bugpattern/DuplicateBranches error (though that will [soon be only a warning](google/error-prone#4700)) by just eliminating the branch. Hopefully that is fine.

RELNOTES=n/a
PiperOrigin-RevId: 700392786
A better link would be gwtproject/gwt#3034, which in turn points to gwtproject/gwt#3319.

But the purpose of the link was to explain why our `ImmutableEnumSet` was _not_ serializable, and it became serializable back in cl/13204390 (as belatedly documented in cl/13216866). I should have removed the comment at that point.

And of course now we've been ripping out GWT serialization entirely, so that that's yet another reason to eliminate this comment.

RELNOTES=n/a
PiperOrigin-RevId: 700411695
PiperOrigin-RevId: 700499139
…ecked warnings.

RELNOTES=n/a
PiperOrigin-RevId: 702798888
This test checked that if `File.exists(someFile)` throws `SecurityException`, `ClassPath` will behave as if `someFile` doesn't exist. This can only happen if there is a `SecurityManager` and it rejects the attempt to check whether `someFile` exists. `SecurityManager` functionality is being removed from Java, so this test won't work, but also the situation it is covering won't happen. While we could do more work to preserve the test on Java versions that still have a `SecurityManager`, it's probably not worth the effort.

RELNOTES=n/a
PiperOrigin-RevId: 703103233
RELNOTES=n/a
PiperOrigin-RevId: 703614216
… `BloomFilter`.

Closes #7494. Fixes #7346.

Thanks to @longlong354 for the original idea.

RELNOTES=n/a
PiperOrigin-RevId: 704025174
`SecurityManager` functionality is being removed from upcoming versions of
Java. There is no straightforward way to achieve what these tests are doing
without having a `SecurityManager`. On the plus side the tests are checking
what happens if a `SecurityManager` forbids certain operations, and of course
if there is no such thing then that can't happen.

RELNOTES=n/a
PiperOrigin-RevId: 704378731
…s://bugs.openjdk.org/browse/JDK-8265237) for JDK 17+.

Implementation strategy:

- No matter what we do, the JDK is going to allocate a `String[]` to guard (presumably) against concurrent mutation. (Paging [Frozen Arrays](https://openjdk.org/jeps/8261007)?)
- Our main ability to optimize around that is to convince the JDK that it can preallocate an array of the proper size. Since the JDK [won't do that in its `Iterable` overload](https://bugs.openjdk.org/browse/JDK-8305774), we want to pass it an array.
- Sadly, the JDK requires that the array be of type `CharSequence[]`, so we can't reuse the result of `toArray()`. Thus, if we want to avoid allocating `toArray()` output _on top of_ a `CharSequence[]` and a `String[]`, we have to write directly to a `CharSequence[]` during iteration over the array, with the array pre-sized based on the collection size (but without relying on that size to exactly match what we get from the iteration).

See discussion in #7532.

RELNOTES=n/a
PiperOrigin-RevId: 704698587
For the mutex change, compare cl/660005124.

Also, sneak in an implementation comment that would have been better in cl/704698587.

RELNOTES=n/a
PiperOrigin-RevId: 704748981
Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action).

Updates `github/codeql-action` from 3.27.5 to 3.27.6
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@f09c1c0...aa57810)

Fixes #7539

RELNOTES=n/a
PiperOrigin-RevId: 704814706
`SecurityManager` functionality is being removed from Java and these tests already fail with the latest JDK snapshots. The problem that the tests address is only pertinent when there actually is a `SecurityManager`, so the need for them evaporates at the same time.

Also update the remaining part of `FinalizableReferenceQueueClassLoaderUnloadingTest` by migrating from JUnit 3 to JUnit 4 and by using Truth assertions.

RELNOTES=n/a
PiperOrigin-RevId: 705230335
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.