Google Guava vs. Apache Commons

我一直在寻找Java中的双向映射实现,偶然发现了这两个库:

  • Google Guava (以前称为“Google Collections”)
  • Apache Commons Collections

两者都是免费的,具有我正在寻找的双向地图实现(Apache中的BidiMap,Google中的BiMap),几乎相同的大小(Apache 493 kB,Google 499 kB)[编辑:不再是真的!]并且似乎在各方面都和我很相似。

我应该选择哪一个,为什么? 是否有一些其他等效的替代品(必须是免费的,至少有双向地图)? 我正在使用最新的Java SE,因此不需要人为地限制Java 5或类似的东西。

在我看来,更好的选择是Guava (以前称为Google集合):

  • 它更现代(有generics)
  • 它完全遵循Collections API要求
  • 它是积极维护的
  • CacheBuilder和它的前身MapMaker简直太棒了

Apache Commons Collections也是一个很好的库,但它长期以来未能提供支持generics的版本(在我看来这是收集API的一个主要缺点)并且通常似乎是在维护/不做-too-much-work-on-it模式最近Commons Collections再次获得了一些动力,但它有一些赶上来做。

如果下载大小/内存占用/代码大小是一个问题,那么Apache Commons Collections可能是更好的候选者,因为它是其他库的常见依赖。 因此,在您自己的代码中使用它也可以在不添加任何其他依赖项的情况下完成。 编辑:这个特殊的“优势”现在已被部分颠覆,因为许多新库实际上依赖于Guava而不是 Apache Commons Collections。

我发现最重要的事情是让Google Collections成为开始的地方:

  • generics(没有generics的集合 – FTL)
  • 与集合框架保持一致(Josh Bloch是此框架中的关键参与者)
  • 正确性。 这些家伙拼命地把这个问题弄好了; 他们有类似25Kunit testing的东西,并且与使API恰到好处有关。

这是一个很棒的Youtubevideo ,由主要作者发表,他很好地讨论了这个图书馆值得了解的内容。

来自常见问题: Google Collections常见问题解答

谷歌为什么要构建所有这些,当它可能试图改进Apache Commons Collections时呢?

Apache Commons Collections非常清楚地无法满足我们的需求。 它不使用generics,这对我们来说是个问题,因为我们讨厌从代码中获取编译警告。 它也长期处于“持有模式”。 我们可以看到,在我们乐意使用它之前需要我们进行相当大的投资才能修复它,与此同时,我们自己的库已经有机地增长了。

Apache库和我们的库之间的一个重要区别是我们的集合非常忠实地遵守它们实现的JDK接口指定的契约。 如果您查看Apache文档,您会发现无数的违规示例。 他们应该如此清楚地指出这些,但仍然偏离标准的收集行为是有风险的! 你必须小心你对这样的collections做什么; 错误总是等待发生。

我们的集合是完全一致的,并且从不违反他们的合同(除了孤立的例外,JDK实现为可接受的违规行为设置了一个强有力的先例)。 这意味着您可以将我们的一个集合传递给任何需要集合的方法,并且相信事情将完全按预期工作。

关于Guava的一个令人讨厌的事情是Multimap不扩展java.util.Map。 如果您有自己的方法可以在Maps上运行,那么它们将无法在Guava Multimaps上运行(Apache MultiMap接口确实扩展了java.util.Map)。 我确信它有一些很好的理由,为什么它的方式,但它也不方便。

另外两件事(我希望我没错)

  • Guava(google集合的新名称)的许可证是Apache License 2.0,意思是:与Apache Commons项目相同
  • 我找不到要下载的文件中的Guava源代码(似乎只有git-access是可能的)