views:

1751

answers:

5

I was looking for a bidirectional map implementation in Java, and stumbled upon these two libraries:

Both are free, have the bidirectional map implementation that I was looking for (BidiMap in Apache, BiMap in Google), are amazingly nearly the same size (Apache 493 kB, Google 499 kB) and seem in all ways pretty similar to me.

Which one should I choose, and why? Are there some other equivalent alternatives (must be free and have at least the bidirectional map)? I'm working with the latest Java SE, so no need to artificially limit to Java 5 or anything like that.

A: 

I hear modern programmers always debating which framework to use, which API to choose. Just use one! It really doesn't matter.

me_here
If I have the freedom to pick something that I may have to live with for the next ten years, I'll gladly spend some energy to compare the alternatives rather than randomly pick one.
Joonas Pulakka
@me_here: Why not just delete this answer instead of getting all these downvotes?
Shervin
+46  A: 

In my opinion the better choice is Google collections (edit: which has since been folded into Guava):

  • it's more modern (generics)
  • it absolutely follows the Collections API requirements
  • it's definitely maintained
  • MapMaker is just plain awesome

Apache Commons Collections is a good library as well, but it 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.

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.

Joachim Sauer
I haven't use the Google Collections for a few months now. I started using it because of the Multimap interface and its implementations, and now I use the static methods in the classes Sets, Lists and Maps for everything that I can. I haven't used MapMaker yet, but I sure will look at it more closely - I have special interest in the weak values implementation.
Ravi Wallau
What I really wonder: why are there no other opinions? Should I be playing the devils advocate? Apache Commons Collections is not a bad library, after all.
Joachim Sauer
Since the Apache lacks generics, I think it's obvious which of these two is the future. Google is the next logical step forward. It's a strange feeling, though, that it's built by The Giant... but as long as it's under a free license it shouldn't matter even if it was built by Microsoft. I guess.
Joonas Pulakka
+23  A: 

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

  • Generics (Collections withough 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.

joeslice
+1 for the video link
Jesper
Great further reading about Google Collections: http://www.javalobby.org/articles/google-collections (an interview with its main creators). Look for the question "What is unique about your approach? How does it differ to, for example, the Apache Commons Collection?"
Jonik
+14  A: 

from the faq: http://code.google.com/p/google-collections/wiki/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.

davideconsonni
A: 

Use Apache for sure . Unless generics is really important to you . Even though can not see why would it stop you from using it still . As much as I like some of the stuff Google they often try to reinvent the wheel and just because it is "Google" does not mean it will always be supported . What happened to Gin , Guice etc.

I am not bagging Google but there is not reason to leave power house libraries from Apache which are tried and tested and go with Google .

Google says that if find better way to do things in your code how many people did you help and yet themselves did exactly that . Instead of fixing Apache or donating their code apache they have "Yet an Other Google Library" Why ?????

Annoyed
Gin, Guice, Collections (Guava) are all under **Apache License**, I fail to see how this isn't enough of a donation.
Bakkal
Publishing content under any licence merely means that terms and conditions of use and distribution of that product are governed by that licence full stop . It is not a donation of any sort . Yes I respect the fact that it is opensource . I am do not want to been see as bagging Google because I love them in general . But lately their philosophy has been along the lines which Microsoft and Apple had all or nothing . These Collections should have been a Apache Project not just under their Licence.I will not use them unless there is something that I can not do with Apache Collections .
Annoyed
@Annoyed: why should a complete re-invention of Apache Collections be an Apache project? Just because the spiritual predecessor was an Apache project? Just because you're used to using "Apache Commons-*Foo*" as your favorite *Foo* library and don't want to unlearn that? Google felt a need, didn't find that need fulfilled and wants some control over the result. Nothing wrong with starting their own project. Especially if they put it under such a liberal license.
Joachim Sauer