Google Guava vs. Apache Commons [closed]

Answer 1

Two other things (I hope I'm not wrong)

• The licence of Guava (new name for google collections) is the Apache License 2.0, meaning: the same one as for Apache Commons project
• I cannot find the source code of Guava in a file to download (it seems only a git-access is possible)

Answer 2

One nasty thing about Guava is that Multimap does not extend java.util.Map. If You have Your own methods that work on Maps they won't work on Guava Multimaps (Apache MultiMap interface does extend java.util.Map). I'm sure that there's some good reason why it's the way it's but it's also inconvenient.

Answer 3

From the faq: Google Collections FAQ

Why did Google build all this, when it could have tried to improve the Apache Commons Collections instead?

The Apache Commons Collections very clearly did not meet our needs. It does not use generics, which is a problem for us as we hate to get compilation warnings from our code. It has also been in a "holding pattern" for a long time. We could see that it would require a pretty major investment from us to fix it up until we were happy to use it, and in the meantime, our own library was already growing organically.

An important difference between the Apache library and ours is that our collections very faithfully adhere to the contracts specified by the JDK interfaces they implement. If you review the Apache documentation, you'll find countless examples of violations. They deserve credit for pointing these out so clearly, but still, deviating from standard collection behavior is risky! You must be careful what you do with such a collection; bugs are always just waiting to happen.

Our collections are fully generified and never violate their contracts (with isolated exceptions, where JDK implementations have set a strong precedent for acceptable violations). This means you can pass one of our collections to any method that expects a Collection and feel pretty confident that things will work exactly as they should.

Answer 4

The most important things I've found that make Google Collections the place to start:

• Generics (Collections without Generics -- FTL)
• Consistency with Collections framework (Josh Bloch was a key player in this framework)
• Correctness. These guys are desperately tied to getting this problem right; they have something like 25K unit tests, and are tied to getting the API just right.

Here's a great Youtube video of a talk that was given by the primary author and he does a good job of discussing what is worth knowing about this library.

Answer 5

In my opinion the better choice is Guava (formerly known as Google collections):

• it's more modern (has generics)
• it absolutely follows the Collections API requirements
• it's actively maintained
• CacheBuilder and it's predecessor MapMaker are just plain awesome

Apache Commons Collections is a good library as well, but it has long failed to provide a generics-enabled version (which is a major drawback for a collections API in my opinion) and generally seems to be in a maintenance/don't-do-too-much-work-on-it mode _{Recently Commons Collections has picked up some steam again, but it has some catching up to do.}.

If download size/memory footprint/code size is an issue then Apache Commons Collections might be a better candidate, since it is a common dependency of other libraries. Therefore using it in your own code as well could potentially be done without adding any additional dependencies. Edit: This particular "advantage" has been partially subverted by now, since many new libraries actually depend on Guava and not on Apache Commons Collections.