219

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) [ed.: no longer true!] 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.

Mike
  • 14,010
  • 29
  • 101
  • 161
Joonas Pulakka
  • 36,252
  • 29
  • 106
  • 169
  • 5
    Surely you should give us the criteria for choosing the library? License, performance, additional dependencies, supporting generics, ... – SteveD Sep 18 '09 at 13:13
  • 1
    Google Collections is available on repo1.maven.org: http://repo1.maven.org/maven2/com/google/collections/google-collections/ – Joachim Sauer Sep 18 '09 at 13:21
  • I stand corrected -- I was looking in com/googlecode – kdgregory Sep 18 '09 at 14:22

5 Answers5

190

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.

Deekshith
  • 1,544
  • 2
  • 14
  • 15
Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
  • 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 Sep 19 '09 at 07:50
  • 3
    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 Sep 20 '09 at 09:53
  • 10
    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 Sep 21 '09 at 10:26
  • 15
    Readers should be aware that this is a *very* old answer and much has changed – Roy Truelove Nov 21 '14 at 22:29
  • 1
    @RoyTruelove It doesn't surprise me that much has changed and I would love to hear your current thoughts on the matter, or perhaps a link to a more recent review/comparison. I like the "immutable by default / mutable only if required" philosophy and the inclusion of generics in guava, but the materials I have been reading may all have been dated like you say this thread has become. – joeA Nov 22 '14 at 22:01
  • @RoyTruelove - Can you please tell us what has changed & whether we can continue to use the guava/google collections libraries ? They have not changed since 2010. I wonder if this is because the code is complete and there are no bugs, or if the project was abandoned. – MasterJoe Sep 04 '16 at 18:11
  • 2
    @testerjoe2 - Sorry, I wrote that comment a long time back and frankly don't remember the reason for it. In hindsight it was a pretty unhelpful one! I didn't realize that the libs haven't changed since 2010, but I do know that they continue to be heavily used, and so I'd say should be safe. If I were starting w/ a new project today I'd probably have a close look at Goldman Sach's collection lib: https://github.com/goldmansachs/gs-collections. When you're one of the world's most evil companies you really should make sure you've got a kickass java collections library. – Roy Truelove Sep 08 '16 at 02:06
  • @RoyTruelove - Thanks. Is the GS collections as frequently used or cited in the software dev industry ? – MasterJoe Sep 15 '16 at 03:21
  • @testerjoe2 probably not. I generally use Apache if I have no specific criteria that I need to meet. – Roy Truelove Sep 16 '16 at 12:48
  • @testerjoe2's comment that the libraries haven't changed much since 2010 is incorrect. Commons Collections, for instance, had a major v4.0 release near the end of 2013 and now supports generics. It would be interesting to see a comparison of the two libraries as they stand today. – vancan1ty Nov 09 '16 at 17:53
78

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.

Hardik Modha
  • 12,098
  • 3
  • 36
  • 40
Davide Consonni
  • 2,094
  • 26
  • 27
73

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.

Matt Fenwick
  • 48,199
  • 22
  • 128
  • 192
joeslice
  • 3,454
  • 1
  • 19
  • 24
  • 1
    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 Jan 04 '10 at 13:30
  • 4
    Apache Commons Collections Version 4 uses generics. http://commons.apache.org/proper/commons-collections/release_4_0.html – Abdull Jul 10 '13 at 01:28
-7

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)
Olivier Faucheux
  • 2,520
  • 3
  • 29
  • 37
  • 20
    Sources? You mean jar which can be attached in Eclipse? [It's here](http://search.maven.org/#artifactdetails%7Ccom.google.guava%7Cguava%7C11.0.2%7Cjar). BTW: What's wrong with `git clone https://code.google.com/p/guava-libraries/` and `git checkout v11.0.2`? – Grzegorz Rożniecki Apr 05 '12 at 13:36
-7

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.

matt
  • 4,614
  • 1
  • 29
  • 32
  • 16
    If you want to use `Multimap` like `Map`, there's always [`asMap()`](http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Multimap.html#asMap()) view. – Grzegorz Rożniecki Sep 03 '12 at 08:55
  • 23
    How do you expect a Multimap to implement java.util.Map? A multi-map is fundamentally different from a map. – sleske Oct 16 '12 at 14:01
  • 1
    Multimap extends Map>.. I suspect G had good reason not to use Map as superinterface though. – matt Oct 17 '12 at 09:51
  • 10
    @lucek: If you look through the Javadoc for `Map`, with the understanding that every reference to `V` will actually be a `Collection`, I think you'll see pretty quickly why it's not a good superinterface for `Multimap`. – ruakh Nov 06 '12 at 18:31