Google Guava vs. Apache Commons

Question

Google Guava vs. Apache Commons

Joo*_*kka 209 java collections apache-commons guava

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

Google Guava(以前称为"Google Collections")
Apache Commons Collections

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

我应该选择哪一个,为什么？是否有其他等效替代方案(必须是免费的并至少具有双向映射)？我正在使用最新的Java SE,所以不需要人为地限制Java 5或类似的东西.

Answer 1

Joa*_*uer 184

在我看来,更好的选择是番石榴(以前称为谷歌收藏):

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

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

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

由于Apache缺乏泛型,我认为很明显这两者中的哪一个是未来.谷歌是向下迈出的合乎逻辑的一步.但是,这是一种奇怪的感觉,它是由巨人建造的......但只要它是免费许可证,即使它是由微软建造的也无所谓.我猜. (10认同)
读者应该意识到这是一个非常老的答案,并且已经发生了很大变化 (10认同)
我真的很想知道:为什么没有其他意见？我应该扮演魔鬼的拥护者吗？毕竟,Apache Commons Collections并不是一个糟糕的库. (3认同)
+1:`MapMaker`太棒了. (3认同)
@ testerjoe2-对不起，我很久以前就写了那条评论，坦率地说不记得它的原因。事后看来，这是非常无益的！我没有意识到这些库自2010年以来就没有改变过，但是我确实知道它们仍在被大量使用，因此我认为应该是安全的。如果我今天开始一个新项目，我可能会仔细看看高盛的收藏库：https：//github.com/goldmansachs/gs-collections。当您是世界上最邪恶的公司之一时，您确实应该确保您拥有一个kickass java集合库。 (2认同)

Answer 2

joe*_*ice 71

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

泛型(没有泛型的集合 - FTL)
与馆藏框架保持一致(Josh Bloch是此框架中的关键人物)
正确性.这些家伙迫切想要解决这个问题; 他们有类似25K单元测试的东西,并且与使API恰到好处有关.

这是一个很棒的Youtube视频,主要作者给出了一个演讲,他很好地讨论了这个图书馆值得了解的内容.

视频链接为+1 (7认同)
Apache Commons Collections Version 4使用泛型.http://commons.apache.org/proper/commons-collections/release_4_0.html (4认同)

Answer 3

Dav*_*nni 71

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

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

Apache Commons Collections非常清楚地无法满足我们的需求.它不使用泛型,这对我们来说是个问题,因为我们讨厌从代码中获取编译警告.它也长期处于"持有模式".我们可以看到,在我们乐意使用它之前,需要我们进行相当大的投资来解决这个问题,与此同时,我们自己的图书馆已经在有机地发展.

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

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

归档时间：	16 年，2 月前
查看次数：	61838 次
最近记录：	7 年，3 月前