我正在寻找Java中的双向映射实现，并偶然发现了这两个库：
两者都是免费的，具有我一直在寻找的双向映射实现（Apache中的BidiMap，Google中的BiMap），令人惊讶的是，它们的大小几乎相同（Apache 493 kB，Google 499 kB）[编辑：不再真实！]，并且在各个方面似乎都与我非常相似。
我应该选择哪一个，为什么？是否有其他等效的替代方案（必须是免费的并且至少具有双向映射）？我正在使用最新的Java SE，所以没有必要人为地限制在Java 5或类似的东西上。
在我看来，更好的选择是番石榴（以前称为Google集合）：
CacheBuilder及其前身MapMaker简直太棒了Apache Commons Collections也是一个很好的库，但它长期以来一直未能提供一个支持泛型的版本（在我看来，这是集合API的一个主要缺点），并且通常似乎处于维护/不要做太多工作的模式最近Commons Collections再次获得了一些动力，但它有一些追赶工作要做。
如果下载大小/内存占用/代码大小是一个问题，那么Apache Commons Collections可能是一个更好的候选者，因为它是其他库的常见依赖项。因此，在您自己的代码中使用它也可以在不添加任何其他依赖项的情况下完成。编辑：这个特殊的“优势”现在已经部分被颠覆了，因为许多新图书馆实际上依赖于Guava而不是Apache Commons Collections。
来自常见问题解答：谷歌收藏常见问题解答
为什么谷歌要建立这一切，而它本可以尝试改进Apache Commons Collections呢？
Apache Commons Collections显然不能满足我们的需求。它不使用泛型，这对我们来说是一个问题，因为我们讨厌从代码中获得编译警告。它也长期处于“持有模式”。我们可以看到，在我们很高兴使用它之前，我们需要我们进行相当大的投资来修复它，与此同时，我们自己的库已经在有机地增长。
Apache库和我们的库之间的一个重要区别是，我们的集合非常忠实地遵守它们实现的JDK接口指定的契约。如果您查看Apache文档，您会发现无数违规示例。他们如此清楚地指出了这些，值得称赞，但是，偏离标准收集行为仍然是有风险的！你必须小心你如何处理这样的集合;错误总是在等待发生。
我们的集合是完全通用的，从不违反它们的契约（除了孤立的例外，其中JDK实现为可接受的违规行为树立了强有力的先例）。这意味着您可以将我们的一个集合传递给任何需要集合的方法，并且非常有信心事情会完全按照它们应该的方式工作。
