Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 232 posts at DZone. You can read more from them at their website. View Full User Profile

Guava is an Heavyweight Library and I Would Like This to Change

  • submit to reddit

Google Guava is an useful library that offers many different but unrelated features:

However, this article is not about those features but about offering a single heavyweight Uber JAR for all. From Google’s point-of-view, providing an Uber library for all projects makes sense: “Hey guys, just add this dependency and it will meet your every requirement”. However, from my point of view, this is just making my applications heavier.

Cohesion is at the root of good software development. Many framework providers, such as Spring and JBoss, release nicely cohesive packages and manage dependencies between them through a Dependency Management tool. What is strange is that most Guava’s features are not coupled together, so a having single library is not mandatory. Even stranger, Guava has previously been released in different JARs but Google stopped doing that with version r03.

I have found no solution beside creating separate JARs and handling dependencies myself, then storing them in a Maven Enterprise Repository. Since these tasks are required for each release, I never found the ROI interesting enough. The easiest way would be for Google to do that at build time.

Dear Google engineers, if by chance you happen to stumble upon this article, I’d be very grateful if you’d consider it.


Published at DZone with permission of Nicolas Frankel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Hendy Irawan replied on Wed, 2014/01/15 - 12:08am

I wish you would have done a bit of research:

Here's the main takeaway:

Hearing the feedback here, my personal main reservation to splitting Guava (well, on top of the possibility of conflict between guava-n and guava-base-m) is that the bulk of the code is located in c.g.c.collect. Any app that uses collect (which, I suspect, is what most apps use) is going to get most of Guava along with it. I did some math on this at one point, but it looks like I never posted it externally:

"Basically everyone is using something from collect, and collect pulls in base+math+primitives. That's about 9000 methods that everyone would be stuck with. Splitting out the remaining 3000 into a separate jar is potentially helpful for teams right on the edge [of Android limits], of course."

So, basically the minimum (i.e. collect) Guava would be 3.2 MB. While the rest is 1.5 MB totalling the 4.7 MB we have now.

Is it worth it? You be the judge.

Hendy Irawan replied on Wed, 2014/01/15 - 12:10am in response to: Hendy Irawan

I just realized that it was me who reported that issue, in April 2011. :-)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.