Guava: Library size and Android

[hamidp]

This is not really a feature request, nor a bug report, but more of a request for comments.

I'm sure that everyone is well aware that using Guava on Android is challenging due to the size of the library. Resolving this problem by splitting up Guava into components is a massive endeavor, and something that the team may not be willing to do.

Given this, can we get clarification on the status of making Guava easier to use on Android? Is it considered a non-issue due to Proguard? Is it something being considered for future releases? If so, which release?

Thank you.

[cgdecker]

We're doing a bunch of thinking about how to make Guava better to use on Android, but it's in the very early stages right now so I don't have much to share as far as what exactly we'll be doing. The size of the jar and how effective or ineffective Proguard is for dealing with that is definitely one big thing we'll be looking at.

[ypresto]

Any progress on this? I want to split classes in com.google.common.collect into categorized modules.

[manijshrestha]

@ypresto, I don't think they have plans to split into modules. (Though there has been a tons of request about it). Have you tried jarjar? I did jarjar to break up a smaller jar with stuff I needed.

[ypresto]

I didn't know about jarjar, it looks great..!
This plugin seems to be good for use with android gradle project. https://github.com/vRallev/jarjar-gradle
Thanks for letting me know!

[manijshrestha]

jarjar will be integrated in new Jack and Jill tool chain. More info at: http://tools.android.com/tech-docs/jackandjill
it is still experimental but would be worth a look as well.

[vbauer]

It will be great to split guava.jar on some atomic jars (something like this: https://github.com/jjzazuet/seeds-libraries)

[ypresto]

For list processing, Optional and Objects Lightweight-Stream-API is good alternative.
It is tiny and has similar API to Java 8.
https://github.com/aNNiMON/Lightweight-Stream-API

[ypresto]

I started miniguava project for smaller library size..!

[landawn]

@ypresto maybe you could take a look at: AbacusUtil: http://www.landawn.com

[lowasser]

Guava-for-Android is something we're working on actively now, in collaboration with Android teams within Google, so I figured I'd discuss some of the work we're doing there and how we expect that to look.

Guava 22 will include a Java 7 backport. We see Android as a key customer of that backport, so the backport will reflect that.

We're not going to split Guava up into multiple jars; we still don't think that's likely to help. We still see the use of ProGuard as key to just about any Android app period. What we're working on includes

• monitoring what code ProGuard retains, so that when you use any particular Guava API, the code ProGuard retains is exactly the code that actually gets used. So far we haven't changed public API, and I'm not sure we will, but we've been reorganizing and inlining code to make sure you're not picking up wasteful code and ProGuard is able to eliminate everything it should.
• redesigning key data structures to reduce or eliminate allocation and memory waste; in some cases we're creating an entirely new implementation to live in the Java 7 branch.
• investigating potential new libraries motivated by Android use cases

By no means will all this work be done by the release of Guava 22, but we're starting with the immutable collections and working outward from there. We'll discuss in the release notes what APIs we've worked over for each release.

[ronshapiro]

@lowasser has done a bunch of work as mentioned above. I think at this point, specific issues would be helpful instead of this umbrella issue now that a lot of the code is more Android-friendly.