Add Java8+ APIs to guava-android

[swankjesse]

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.

[cpovirk]

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]

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]

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).

[TWiStErRob]

@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]

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]

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

[cpovirk]

33.2.0 adds Collector APIs, including Sets.immutableEnumSet, to guava-android.

Barring surprises, we'll add most Java 8+ APIs in the next release or thereafter.