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

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

Closed
msgilligan opened this issue Sep 21, 2023 · 2 comments
Closed
Assignees

Comments

@msgilligan
Copy link

The documentation says that if you are using Android you should use the -android JAR. It also says that the -android JAR is JDK 7 compatible. If my library targets JDK and Android that is JDK 8 compatible (e.g. API 26 or above) is there any reason to not use the -jre version as a dependency in my library?

The documentation does not seem to answer this question or explain when or if the -jre version can be used on Android.

@cpovirk
Copy link
Member

cpovirk commented Sep 21, 2023

I think the docs give a pretty direct answer on this: "If you need support for Android, use the Android flavor."

But it's a reasonable to wonder whether there might actually be some subtleties hiding behind that: We already say a lot, so it's likely that we wouldn't be able to squeeze in any further subtleties :) And of course you mention the new versions of Android, and there's library desugaring, too.

In the end, I would still say to stick with the Android flavor. While apparently some people have used parts of guava-jre under Android, I don't want to guarantee that it will work today, much less that it will continue to work, especially given that guava-jre will someday require something newer than Java 8 (not that there are plans for that yet, given that we haven't even done #6549). For example, some people might have assumed (though you did not, kudos :)) that API Level 24 would be enough, since that's when java.util.stream was added. But that would be ignoring your example of java.time in API Level 26 (and, similarly, our recent internal use of MethodHandle). It's possible that API Level 26 is sufficient today, but we don't test for that, and we don't promise to stick to it.

Additional, the Android flavor has implementations optimized for code size and for reducing allocation, while the JVM flavor is more tuned for speed in that environment.

Plus, you might have noticed that my "some people have used parts of guava-jre under Android" link goes to a bug report in which a user was having trouble getting Gradle to use the JRE flavor under Android, thanks to our recent addition of Gradle Module Metadata. I suggested a possible workaround, but I don't know whether it worked. (And I see, now that I'm thinking about it more, that I should have pushed back harder on using the JRE flavor under Android there, too. I'll edit my post to link back to here.)

The one bit of good news is that we did recently take another baby step toward adding Java 8+ APIs to guava-android (since Android VMs are very permissive of unrecognized types in APIs that you don't use). There is still a bunch to be done, but that is likely to be the best way forward. You can follow along at #6567.

@msgilligan
Copy link
Author

Thanks @cpovirk! That was very helpful!

copybara-service bot pushed a commit that referenced this issue Nov 6, 2023
(somewhat relevant to #6725 and #6801, but this CL is about the good things about the Android flavor, not the risks of the JRE flavor)

RELNOTES=n/a
PiperOrigin-RevId: 579831040
cpovirk added a commit that referenced this issue Nov 6, 2023
(somewhat relevant to #6725 and
#6801, but this CL is about the
good things about the Android flavor, not the risks of the JRE flavor)
copybara-service bot pushed a commit that referenced this issue Nov 6, 2023
(somewhat relevant to #6725 and #6801, but this CL is about the good things about the Android flavor, not the risks of the JRE flavor)

RELNOTES=n/a
PiperOrigin-RevId: 579886456
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants