Add Java8+ APIs to guava-android #6567

swankjesse · 2023-06-20T13:07:11Z

When we upgraded Truth we started getting crashes like this:

java.lang.NoSuchMethodError: 'java.util.stream.Collector com.google.common.collect.Sets.toImmutableEnumSet()'
	at com.android.resources.ResourceType.<clinit>(ResourceType.java:175)
	at app.cash.paparazzi.internal.DynamicResourceIdManager$IdProvider.<init>(DynamicResourceIdManager.kt:14)
	at app.cash.paparazzi.internal.DynamicResourceIdManager.<init>(DynamicResourceIdManager.kt:28)
	at app.cash.paparazzi.internal.PaparazziCallback.<init>(PaparazziCallback.kt:52)
	at app.cash.paparazzi.Paparazzi.prepare(Paparazzi.kt:145)
	at app.cash.paparazzi.Paparazzi$apply$statement$1.evaluate(Paparazzi.kt:116)

As @TWiStErRob explains on Paparazzi #906:

This came back in Truth 1.1.5 because Paparazzi depends on 32.0.0-jre vs Truth uses 32.0.1-android, and the higher version number wins. Looks like the workaround has to stay.

A very simple fix for our problem is for Guava to support the toImmutableEnumSet() function on all platforms. I don’t believe this function needs the same implementation on all platforms; it just needs something so we don’t crash at runtime.

The text was updated successfully, but these errors were encountered:

cpovirk · 2023-06-21T15:10:28Z

Sorry, this kind of problem crops up occasionally. See, e.g., https://stackoverflow.com/q/65646026/28465.

Since we dropped support for Java 7 back in 31.0, we can in theory now get away with adding methods that use Java 8+ types like Collector in their signatures. That's true even if Android users don't use library desugaring. (And I'm not sure we could require them to use it yet. Issue 203113147 would help but probably not be sufficient).) Thankfully, we can rely on the Android VM to ignore those methods unless someone actually calls them. (And maybe we can use @RequiresApi to prevent people from calling them by accident. But that may annoy people who target older versions of Android but use library desugaring (since Android Lint would still report an error for calls to the method, even though it's actually safe for them). And maybe the androidx.annotation:annotation-jvm dependency would become another obstacle to modularization? But this is becoming a long digression.)

Can we get away with it in practice? I'm going to run a test with toImmutableEnumSet() specifically to see what happens. I do know that we've seen trouble when testing another Java 8+ thing—specifically, adding one default method, which I might have guessed would be easier than adding methods that use Java 8+ APIs. But adding another default method appeared to work fine.... We're never going to feel completely safe with making these kinds of changes, but we'll have to take the plunge eventually. We took a baby step in this direction by adding a usage of a class that isn't support on Android at all in 32.0.0 (namely, a usage of AnnotatedType). That seems to have gone OK so far.

I do note that this general class of problem will exist as long as guava-jre contains any APIs that guava-android doesn't. And I'm unsure whether the two will fully converge. But this problem is a reason to consider making them converge, even if it doesn't make fully sense. And even if they don't fully converge, there's a big difference between missing commonly used APIs (like our Collector implementations) and missing only the more obscure things.

Independent of all that, one thing that we really, really should do is finally get back to #3683: It is designed to make Gradle pick the maximum numeric part of the version number for Guava but then choose -android or -jre as appropriate. That PR is frequently on my mind; I just need to find an hour on a day when I'm feeling up for a deep dive and when nothing else is on fire :)

(For non-Gradle users, we could additionally consider releasing separate truth-android and truth-jre artifacts, which would have identical class files but would have a different Guava dep. (I wonder if any tools had to go to effort to specifically recognize Guava's unusual version numbers, and I wonder if a similar change in Truth would cause them similar issues. And I wonder if the Truth change would "look bad" even if it turned out to be a net win in fighting the Guava problem.... For anyone else at Google following along, see bug 177249370.)

cpovirk · 2023-06-22T14:09:37Z

It looks like we'd be able to add toImmutableEnumSet() to guava-android without breaking anything inside Google.

I'm thinking I might try something like this:

Pick a less commonly used class (ImmutableTable?) whose Java 8+ methods we could add to guava-android. (Bonus: The relevant ImmutableTable methods return a Collector, so users are unlikely to call the methods unless they're also using other Java 8+ APIs. This means that we can probably count on existing NewApi enforcement without having to use @RequiresApi ourselves. And really, the Collector APIs are probably a sizable portion of what users want, so it's good to try adding one of them.)
Try actually submitting that internally and seeing it get used.
Consider repeating that for other APIs.
Release the first such API publicly.
If all goes well, do more of that, thinking more about @RequiresApi.

I don't expect to add any of the APIs in the next Guava release. But that's only because we've had a surprising number of changes that I'd like to release soonish so that users can pick them out without taking even a small risk from ImmutableTable.toImmutableTable (or whatever we end up adding). But we won't need to wait a year before releasing again :)

(I'm going to generalize this issue to be about the overall effort.)

cpovirk · 2023-06-22T14:44:42Z

Actually, we added Stopwatch.elapsed() (which returns a Java 8 Duration) to our internal Android copy a while back, but I'd forgotten. It's gone well. But I'd note that we added special support to our Java compatibility enforcement (in this change to AndroidJdkLibsChecker), so we might want similar enforcement for future changes (albeit perhaps not for Collector APIs, given what I said above).

…-android` (but don't do so yet). Progress toward #6567 RELNOTES=n/a PiperOrigin-RevId: 542547311

…-android` (but don't do so yet). Progress toward #6567 RELNOTES=n/a PiperOrigin-RevId: 543468006

To be conservative, this commit does not removes most annotation artifacts from Gradle's runtime classpath, only j2objc-annotations. The other artifacts contain at least some annotations with RUNTIME visibility (IIRC). (Even this change could theoretically affect users who assume that they can read CLASS-retention annotations (of which j2objc-annotations has some) from bytecode and find them in the runtime classpath. But that seems unlikely, especially for j2objc annotations.) We may consider being more aggressive in the future. For now, this particular commit addresses #2824 for Gradle users just a tiny bit, and it helps with the problem that prompted #6567. Fixes #3683 RELNOTES=Added [Gradle Module Metadata](https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html). If you use Gradle 6 or higher, Gradle can automatically intelligently resolve conflicts between `guava-android` and `guava-jre`, among [other benefits](#3683). PiperOrigin-RevId: 337348979

To be conservative, this commit does not removes most annotation artifacts from Gradle's runtime classpath, only j2objc-annotations. The other artifacts contain at least some annotations with RUNTIME visibility (IIRC). (Even this change could theoretically affect users who assume that they can read CLASS-retention annotations (of which j2objc-annotations has some) from bytecode and find them in the runtime classpath. But that seems unlikely, especially for j2objc annotations.) We may consider being more aggressive in the future. For now, this particular commit addresses #2824 for Gradle users just a tiny bit, and it helps with the problem that prompted #6567. Fixes #3683 RELNOTES=Added [Gradle Module Metadata](https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html). If you use Gradle 6 or higher, Gradle can automatically intelligently resolve conflicts between `guava-android` and `guava-jre`, among [other benefits](#3683). PiperOrigin-RevId: 544108700

TWiStErRob · 2023-06-30T14:05:25Z

@swankjesse, from my reading the original issue will be solved by ce78fc6, see the section titled "Selecting the appropriate flavor" in 32.1 release notes, will test when 32.1.1 is released.

cpovirk · 2023-06-30T15:30:42Z

Thanks, yes, that's the theory. I've released 32.1.1. Sorry for the trouble with 32.1.0. Please do let us know how it goes.

TWiStErRob · 2023-06-30T23:10:31Z

Not trivial... got a capability conflict, will have to look deeper later.

The primary change comes as a followup to cl/543468006: Now that the Google-internal `ImmutableTable` declares [methods with Java 8+ types in their signatures](#6567), we get a `NoClassDefFoundError` when performing reflection on the class under old Android emulators. We perform reflection only when (a) using `NullPointerTester` or (b) using serialization. So we (a) stop running `NullPointerTester` under an Android emulator (though we continue to run the same `guava-android` test under a JVM) and (b) specify a `serialVersionUID` so that serialization doesn't need to compute one. (Specifying `serialVersionUID` was our MO for a while. Perhaps we just got careless, and perhaps we should be more diligent. Alternatively, perhaps we should change the `serialVersionUID` every release or so so as to encourage people [not to persist serialized data](https://github.com/google/guava#important-warnings). I at least went to a tiny bit of effort to keep `guava-jre` and `guava-android` on different `serialVersionUID` values, though maybe that's more likely to cause needless trouble someday than to prevent it?) The other change is to avoid running another GC test under an Android emulator. We'd originally done this for one copy of `AbstractIteratorTester` in cl/444929745, but for whatever reason, we didn't need it for the other copy until (I assume) cl/546307327 and its switch to a different emulator version. RELNOTES=n/a PiperOrigin-RevId: 550670580

The primary change comes as a followup to cl/543468006: Now that the Google-internal `ImmutableTable` declares [methods with Java 8+ types in their signatures](#6567), we get a `NoClassDefFoundError` when performing reflection on the class under old Android emulators. We perform reflection only when (a) using `NullPointerTester` or (b) using serialization. So we (a) stop running `NullPointerTester` under an Android emulator (though we continue to run the same `guava-android` test under a JVM) and (b) specify a `serialVersionUID` so that serialization doesn't need to compute one. (Specifying `serialVersionUID` was our MO for a while. Perhaps we just got careless, and perhaps we should be more diligent. Alternatively, perhaps we should change the `serialVersionUID` every release or so so as to encourage people [not to persist serialized data](https://github.com/google/guava#important-warnings). I at least went to a tiny bit of effort to keep `guava-jre` and `guava-android` on different `serialVersionUID` values, though maybe that's more likely to cause needless trouble someday than to prevent it?) The other change is to avoid running another GC test under an Android emulator. We'd originally done this for one copy of `AbstractIteratorTester` in cl/444929745, but for whatever reason, we didn't need it for the other copy until (I assume) cl/546307327 and its switch to a different emulator version. RELNOTES=n/a PiperOrigin-RevId: 550872250

…/docs/api/java.base/java/util/SequencedCollection.html) methods to `ImmutableSortedSet`. There are a couple reasons that this is maybe kind of nice, and then there's my real motivation for doing it. Reasons that this is maybe kind of nice: - We add `@DoNotCall` and `@Deprecated` to the mutator methods, as usual. - We refine the return type of `reversed()` to `ImmutableSortedSet`. But again, those aren't my real motivation. (If they _were_ my real motivation, you might notice, then there would be no reason for us to override `getFirst()` and `getLast()`.) My _real_ motivation is that we are looking to give `guava-android` APIs that use Java 8+ types in their signatures, such as `ImmutableSet.toImmutableSet`. And as a result of some part of those changes, we start seeing errors in some of our Google-internal build rules. Those errors come because some the desugaring process is inserting its own versions of `getFirst` and friends, versions that refer to the desugar-provided copies of `SortedSet` and `NavigableSet`, which our build process then looks for but cannot find. Since this CL is preparation for adding `ImmutableSet.toImmutableSet`, it constitutes further progress toward #6567 RELNOTES=`collect`: Added [`SequencedCollection`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/SequencedCollection.html) methods to `ImmutableSortedSet`. PiperOrigin-RevId: 575207552

…/docs/api/java.base/java/util/SequencedCollection.html) methods to `ImmutableSortedSet`. There are a couple reasons that this is maybe kind of nice, and then there's my real motivation for doing it. Reasons that this is maybe kind of nice: - We add `@DoNotCall` and `@Deprecated` to the mutator methods, as usual. - We refine the return type of `reversed()` to `ImmutableSortedSet`. But again, those aren't my real motivation. (If they _were_ my real motivation, you might notice, then there would be no reason for us to override `getFirst()` and `getLast()`.) My _real_ motivation is that we are looking to give `guava-android` APIs that use Java 8+ types in their signatures, such as `ImmutableSet.toImmutableSet`. And as a result of some part of those changes, we start seeing errors in some of our Google-internal build rules. Those errors come because some the desugaring process is inserting its own versions of `getFirst` and friends, versions that refer to the desugar-provided copies of `SortedSet` and `NavigableSet`, which our build process then looks for but cannot find. Since this CL is preparation for adding `ImmutableSet.toImmutableSet`, it constitutes further progress toward #6567 RELNOTES=`collect`: Added [`SequencedCollection`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/SequencedCollection.html) methods to `ImmutableSortedSet`. PiperOrigin-RevId: 575459262

…`mergeFunction` returns `null`. (The test is Google-internal for now because we're in the process of reshuffling our `Collector` tests to make them run under Android as part of #6567. Also, we skip the test under GWT+J2CL because of a bug in their implementation of `Collectors.toMap`.) This addresses the main part of #6824, but I'm keeping the bug open as a prompt to recognize our nullness annotations in the future. RELNOTES=n/a PiperOrigin-RevId: 580635720

…`mergeFunction` returns `null`. (The test is Google-internal for now because we're in the process of reshuffling our `Collector` tests to make them run under Android as part of #6567. Also, we skip the test under GWT+J2CL because of a bug in their implementation of `Collectors.toMap`.) This addresses the main part of #6824, but I'm keeping the bug open as a prompt to recognize our nullness annotations in the future. RELNOTES=n/a PiperOrigin-RevId: 580661189

…id`. This CL is further progress toward #6567 RELNOTES=n/a PiperOrigin-RevId: 580262625

…id`. This CL is further progress toward #6567 RELNOTES=n/a PiperOrigin-RevId: 581031659

cpovirk · 2023-11-13T21:30:05Z

I was just reminded that people see problems sometimes on the annotation-processor classpath when guava-android sneaks in. (I believe Dagger, for example, still avoids our Collector APIs for that reason.)

Anyway, my hope now is to:

back out 945ce37 (which I don't think we actually need)
add the new Collector APIs as package-private (so that no one can come to depend on them yet but so that we have a chance to shake out problems that might arise)
cut a release
if all goes well, promote the Collector APIs to public but with @Beta (but really hope that we don't have to back them out)
cut another release
if all goes well, start adding other Java 8 APIs

I still kind of expect that to blow up for someone somehow, probably on account of performing reflection on our classes. My hope would be that anyone who is in a position to use reflection would also be in a position to enable library desugaring. But that's why we'd run the test... :)

…droid codebase. This is a test before exposing them as `public`. We have successfully used them inside Google, but we want to test as much as we can before adding them to our open-source project, since we don't want to have to remove them later. Package-private APIs are of course of no use to users. However, there mere existence may be enough to cause problems for build tools or for Android apps that perform runtime reflection on the Guava classes (which incidentally we do not recommend, for this and other reasons). Our hope is that such problems are rare to nonexistent or, failing that, that they can be solved by enabling [library desugaring](https://developer.android.com/studio/write/java8-support#library-desugaring) for any affected apps. Please do report any problems that this change causes. The next step before exposing the APIs as `public` will likely be to expose an override of `spliterator()`. Since that API will be an override, it is more likely to be preserved by optimizers, which might remove the unused `Collector` APIs. (Sadly, we can't prevent that by inserting a usage of the `Collector` APIs in "real code" because that would require all our users to enable library desugaring.) (Originally, I'd planned to expose `spliterator()` immediately, as discussed in cl/576629272. In fact, that CL _did_ expose the method. However, we never released it. (And even if we had, I think we could remove it, since either it's an override (in which case calls to it will continue to work after it's removed) or it's not (in which case Java 8 APIs aren't available, so calls to it would never have worked.) But I think the approach of this current CL is more conservative.) If all goes well, we'll then expose the APIs as `public`. We might considering using `@Beta` for a time, but we'd be unlikely to remove them, so again, please report any problems that this change or any future Java-8-API change causes you. This change is further progress toward #6567. RELNOTES=This version of `guava-android` contains some package-private methods whose signature includes the Java 8 `Collector` API. This is a test to identify any problems before we expose those methods publicly to users. Please report any problems that you encounter. PiperOrigin-RevId: 588869192

…droid codebase. This is a test before exposing them as `public`. We have successfully used them inside Google, but we want to test as much as we can before adding them to our open-source project, since we don't want to have to remove them later. Package-private APIs are of course of no use to users. However, there mere existence may be enough to cause problems for build tools or for Android apps that perform runtime reflection on the Guava classes (which incidentally we do not recommend, for this and other reasons). Our hope is that such problems are rare to nonexistent or, failing that, that they can be solved by enabling [library desugaring](https://developer.android.com/studio/write/java8-support#library-desugaring) for any affected apps. Please do report any problems that this change causes. The next step before exposing the APIs as `public` will likely be to expose an override of `spliterator()`. Since that API will be an override, it is more likely to be preserved by optimizers, which might remove the unused `Collector` APIs. (Sadly, we can't prevent that by inserting a usage of the `Collector` APIs in "real code" because that would require all our users to enable library desugaring.) (Originally, I'd planned to expose `spliterator()` immediately, as discussed in cl/576629272. In fact, that CL _did_ expose the method. However, we never released it. (And even if we had, I think we could remove it, since either it's an override (in which case calls to it will continue to work after it's removed) or it's not (in which case Java 8 APIs aren't available, so calls to it would never have worked.) But I think the approach of this current CL is more conservative.) If all goes well, we'll then expose the APIs as `public`. We might considering using `@Beta` for a time, but we'd be unlikely to remove them, so again, please report any problems that this change or any future Java-8-API change causes you. (This CL requires lots of `@IgnoreJRERequirement` annotations. In an ideal world, we'd run Animal Sniffer twice: one run that allows APIs that require library desugaring and one that doesn't, with our classes' using a separate `@IgnoreJRERequirement`-style annotation for APIs like these.) This change is further progress toward #6567. RELNOTES=This version of `guava-android` contains some package-private methods whose signature includes the Java 8 `Collector` API. This is a test to identify any problems before we expose those methods publicly to users. Please report any problems that you encounter. PiperOrigin-RevId: 588869192

…droid codebase. This is a test before exposing them as `public`. We have successfully used them inside Google, but we want to test as much as we can before adding them to our open-source project, since we don't want to have to remove them later. Package-private APIs are of course of no use to users. However, there mere existence may be enough to cause problems for build tools or for Android apps that perform runtime reflection on the Guava classes (which incidentally we do not recommend, for this and other reasons). Our hope is that such problems are rare to nonexistent or, failing that, that they can be solved by enabling [library desugaring](https://developer.android.com/studio/write/java8-support#library-desugaring) for any affected apps. Please do report any problems that this change causes. The next step before exposing the APIs as `public` will likely be to expose an override of `spliterator()`. Since that API will be an override, it is more likely to be preserved by optimizers, which might remove the unused `Collector` APIs. (Sadly, we can't prevent that by inserting a usage of the `Collector` APIs in "real code" because that would require all our users to enable library desugaring.) (Originally, I'd planned to expose `spliterator()` immediately, as discussed in cl/576629272. In fact, that CL _did_ expose the method. However, we never released it. (And even if we had, I think we could remove it, since either it's an override (in which case calls to it will continue to work after it's removed) or it's not (in which case Java 8 APIs aren't available, so calls to it would never have worked.) But I think the approach of this current CL is more conservative.) If all goes well, we'll then expose the APIs as `public`. We might considering using `@Beta` for a time, but we'd be unlikely to remove them, so again, please report any problems that this change or any future Java-8-API change causes you. (This CL requires lots of `@IgnoreJRERequirement` annotations. In an ideal world, we'd run Animal Sniffer twice: one run that allows APIs that require library desugaring and one that doesn't, with our classes' using a separate `@IgnoreJRERequirement`-style annotation for APIs like these.) This change is further progress toward #6567. RELNOTES=This version of `guava-android` contains some package-private methods whose signature includes the Java 8 `Collector` API. This is a test to identify any problems before we expose those methods publicly to users. Please report any problems that you encounter. PiperOrigin-RevId: 589183735

cpovirk · 2024-02-01T16:09:24Z

I got to experience the NoSuchMethodError issue myself again with a few projects (Gradle and Bazel) when I updated them to Truth 1.3.0.

The plan is still to add the APIs to guava-android. And back in December, I published https://github.com/google/guava/releases/tag/v33.0.0 to add some as package-private to shake out any problems that might arise.

If your friends use guava-android but haven't updated to 33.0.0 yet, please encourage them to do so and then to report any problems. If we don't hear of problems, I'll start exposing APIs publicly. That should help with the NoSuchMethodError issue, and it should be useful to Android developers for its own sake.

…r classes. This is a further attempt to shake out any problems in advance of exposing "real" Java 8 APIs (#6567). If something goes wrong with `spliterator()`, I think we could remove it without breaking callers: Either it's an override (in which case calls to it will continue to work after it's removed) or it's not (in which case Java 8 APIs aren't available, so calls to it would never have worked.) RELNOTES=n/a PiperOrigin-RevId: 603759524

…r classes. This is a further attempt to shake out any problems in advance of exposing "real" Java 8 APIs (#6567). If something goes wrong with `spliterator()`, I think we could remove it without breaking callers: Either it's an override (in which case calls to it will continue to work after it's removed) or it's not (in which case Java 8 APIs aren't available, so calls to it would never have worked.) RELNOTES=n/a PiperOrigin-RevId: 603812702

This makes another good trial balloon for #6567 because it's in our testlib, where the stakes are lower. (Granted, the testlib is also much less commonly used, so we won't learn a lot from this trial.) RELNOTES=`testing`: Exposed `FakeTicker` `Duration` methods to Android users. PiperOrigin-RevId: 604345288

This makes another good trial balloon for #6567 because it's in our testlib, where the stakes are lower. (Granted, the testlib is also much less commonly used, so we won't learn a lot from this trial.) RELNOTES=`testing`: Exposed `FakeTicker` `Duration` methods to Android users. PiperOrigin-RevId: 604629836

…package-private method. (The latter prepares for [Android compatibility for Java 8 APIs](#6567).) RELNOTES=n/a PiperOrigin-RevId: 626483101

…package-private method. (The latter prepares for [Android compatibility for Java 8 APIs](#6567).) RELNOTES=n/a PiperOrigin-RevId: 627098517

cpovirk changed the title ~~Support Sets.toImmutableEnumSet() on Android~~ Add Java8+ APIs to guava-android Jun 22, 2023

cpovirk self-assigned this Jun 22, 2023

cpovirk added type=enhancement Make an existing feature better package=general P3 labels Jun 22, 2023

copybara-service bot pushed a commit that referenced this issue Jun 26, 2023

Prepare to make ImmutableTable.toImmutableTable available in `guava…

6a7ebfa

…-android` (but don't do so yet). Progress toward #6567 RELNOTES=n/a PiperOrigin-RevId: 542547311

copybara-service bot mentioned this issue Jun 26, 2023

Prepare to make ImmutableTable.toImmutableTable available in guava-android (but don't do so yet). #6589

Closed

copybara-service bot pushed a commit that referenced this issue Jun 26, 2023

Prepare to make ImmutableTable.toImmutableTable available in `guava…

39c45d2

…-android` (but don't do so yet). Progress toward #6567 RELNOTES=n/a PiperOrigin-RevId: 543468006

copybara-service bot mentioned this issue Jun 28, 2023

Publish Gradle Module Metadata with Variants. #6603

Closed

jrodbx mentioned this issue Jul 8, 2023

Update dependency com.google.guava:guava to v32.1.3-jre - autoclosed cashapp/paparazzi#966

Closed

1 task

cpovirk mentioned this issue Jul 15, 2023

update to Guava 32.1.1-android: duplicate classes - not solved by advice in release notes #6618

Open

copybara-service bot mentioned this issue Jul 25, 2023

Fix Google-internal common.collect tests under an Android emulator. #6652

Closed

This was referenced Jul 26, 2023

Incompatibility with the last version of truth google/compile-testing#363

Closed

guava:32.1.1-jre conflicts with google-cloud-datastore:2.16.0 #6642

Closed

cpovirk mentioned this issue Sep 21, 2023

Documentation/Question: When can the JRE Guava JAR be used on Android? #6725

Closed

copybara-service bot mentioned this issue Oct 21, 2023

Add [SequencedCollection](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/SequencedCollection.html) methods to ImmutableSortedSet. #6796

Closed

cpovirk mentioned this issue Oct 24, 2023

Forcing guava JRE versions in Android projects with new metadata is too tedious #6801

Open

copybara-service bot mentioned this issue Oct 25, 2023

Prepare to make ImmutableSet.toImmutableSet available in guava-android (but don't do so yet). #6804

Closed

copybara-service bot mentioned this issue Nov 9, 2023

Prepare to expose (all?) remaining collectors as part of guava-android. #6829

Closed

copybara-service bot pushed a commit that referenced this issue Nov 9, 2023

Prepare to expose (all?) remaining collectors as part of `guava-andro…

3f3c9a0

…id`. This CL is further progress toward #6567 RELNOTES=n/a PiperOrigin-RevId: 580262625

copybara-service bot pushed a commit that referenced this issue Nov 9, 2023

Prepare to expose (all?) remaining collectors as part of `guava-andro…

ed21dbb

…id`. This CL is further progress toward #6567 RELNOTES=n/a PiperOrigin-RevId: 581031659

copybara-service bot mentioned this issue Dec 8, 2023

Include our Collector APIs as package-private in our open-source Android codebase. #6865

Merged

TWiStErRob mentioned this issue Jan 7, 2024

x.y.z-jre version has -android.jar artifact with missing -jre classes #6904

Closed

1 task

jrodbx mentioned this issue Jan 16, 2024

1.3.1 -> 1.3.2 java.lang.IllegalAccessError: class com.android.resources.ResourceType tried to access method 'java.util.stream.Collector cashapp/paparazzi#1231

Closed

copybara-service bot mentioned this issue Feb 2, 2024

Add an overload of spliterator() to the Android flavor of one of our classes. #6957

Merged

copybara-service bot mentioned this issue Feb 6, 2024

Expose FakeTicker Duration methods to Android users. #6964

Merged

SimonMarquis mentioned this issue Feb 21, 2024

chore(deps): bump app.cash.paparazzi from 1.3.1 to 1.3.2 adevinta/spark-android#895

Closed

copybara-service bot mentioned this issue Apr 21, 2024

Add a missing @since tag, and remove @FunctionalInterface from a package-private method. #7173

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Java8+ APIs to guava-android #6567

Add Java8+ APIs to guava-android #6567

swankjesse commented Jun 20, 2023

cpovirk commented Jun 21, 2023 •

edited

cpovirk commented Jun 22, 2023

cpovirk commented Jun 22, 2023

TWiStErRob commented Jun 30, 2023

cpovirk commented Jun 30, 2023

TWiStErRob commented Jun 30, 2023

cpovirk commented Nov 13, 2023

cpovirk commented Feb 1, 2024

Add Java8+ APIs to guava-android #6567

Add Java8+ APIs to guava-android #6567

Comments

swankjesse commented Jun 20, 2023

cpovirk commented Jun 21, 2023 • edited

cpovirk commented Jun 22, 2023

cpovirk commented Jun 22, 2023

TWiStErRob commented Jun 30, 2023

cpovirk commented Jun 30, 2023

TWiStErRob commented Jun 30, 2023

cpovirk commented Nov 13, 2023

cpovirk commented Feb 1, 2024

cpovirk commented Jun 21, 2023 •

edited