我在Java中寻找bidirectional map实现，偶然发现了这两个库：
两者都是免费的，具有我正在寻找的双向地图实现（Apache中的BidiMap，Google中的BiMap），几乎相同的大小（Apache 493 kB，Google 499 kB）[编辑：不再是真的！并且在各方面看起来与我非常相似。
我应该选择哪一个，为什么？是否有其他等效替代方案（必须是免费的并至少具有双向映射）？我正在使用最新的Java SE，所以不需要人为地限制Java 5或类似的东西。
答案 0 :(得分：181)
在我看来，更好的选择是Guava（以前称为Google收藏）：
CacheBuilder它的前任MapMaker简直太棒了Apache Commons Collections也是一个很好的库，但它很长时间未能提供一个支持泛型的版本（在我看来，这是一个主要缺陷的集合API）并且通常看起来像处于维护/不做太多工作的模式最近Commons Collections再次获得了一些动力，但它有一些赶上来做。。
如果下载大小/内存占用/代码大小是一个问题，那么Apache Commons Collections可能是更好的候选者，因为它是其他库的常见依赖。因此，在您自己的代码中使用它也可以在不添加任何其他依赖项的情况下完成。编辑：这个特殊的“优势”现在被部分颠覆了，因为许多新的库实际上依赖于Guava，而不是在Apache Commons Collections上。
答案 1 :(得分：70)
我发现最重要的事情是让Google Collections成为开始的地方：
这是主要作者发表的一篇很棒的Youtube video演讲，他很好地讨论了有关这个图书馆的知识。
答案 2 :(得分：69)
来自常见问题： Google Collections FAQ
为什么谷歌可以构建所有这些，当它可能试图改进Apache Commons Collections时呢？
Apache Commons Collections非常清楚地无法满足我们的需求。它 不使用泛型，这对我们来说是一个问题，因为我们讨厌得到 我们的代码中的编译警告。它也一直在“持有 模式“很长一段时间。我们可以看到它需要一个漂亮的 我们的主要投资来解决它，直到我们乐意使用它， 与此同时，我们自己的图书馆已经有机地发展了。
Apache库和我们的库之间的一个重要区别是 我们的藏品非常忠实地遵守了指定的合同 他们实现的JDK接口。如果你查看Apache 文档，你会发现无数的违规行为。他们 值得赞扬的是指出这些如此清楚，但仍然偏离 从标准的收集行为是有风险的！你一定要小心 你做这样的收藏;错误总是等待发生。
我们的收藏品完全一致，永远不会违反合同 （有一些孤立的例外，JDK实现设置强大 可接受的违法行为的先例）。这意味着你可以通过其中一个 我们的集合到任何期望Collection和感觉的方法 非常有信心，事情会完全按照自己的意愿运作。
答案 3 :(得分：-6)
关于Guava的一个令人讨厌的事情是Multimap不扩展java.util.Map。如果您有自己的方法可以在Maps上工作，那么它们将无法在Guava Multimaps上运行（Apache MultiMap接口确实扩展了java.util.Map）。我确信它有一些很好的理由，为什么它是这样的，但它也很不方便。
答案 4 :(得分：-7)
另外两件事（我希望我没错）