Google Guava与Apache Commons [关闭]

212

我一直在寻找Java中的双向地图实现，偶然发现了这两个库：

Google Guava（以前称为“ Google Collections”）
Apache Commons集合

两者都是免费的，具有我一直在寻找的双向地图实现（Apache中的BidiMap，谷歌中的BiMap），尺寸几乎惊人地相同（Apache 493 kB，Google 499 kB）[ed .：不再是真的！在所有方面都与我非常相似。

我应该选择哪一个，为什么？还有其他等效的替代方法（必须免费并且至少具有双向地图）吗？我正在使用最新的Java SE，因此无需人为地限制为Java 5或类似的东西。

— 乔纳斯·普拉卡（Joonas Pulakka）
source

5

当然，您应该给我们选择图书馆的标准吗？许可，性能，其他依赖项，支持通用名称……

— SteveD

1

谷歌集合可以用repo1.maven.org：repo1.maven.org/maven2/com/google/collections/...

— 约阿希姆·绍尔

我的立场是正确的-我在寻找com / googlecode

— kdgregory

185

我认为更好的选择是Guava（以前称为Google收藏）：

它更现代（具有泛型）
它绝对遵循Collections API要求
积极维护
CacheBuilder它的前身MapMaker简直很棒

Apache Commons Collections也是一个很好的库，但是长期以来它一直未能提供支持泛型的版本（在我看来，这是Collections API 的主要缺点），并且通常看起来是在维护/不做太多的工作模式_{最近，Commons Commons Collections再次}振作_{起来，但还有一些工作要做。}。

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

— 约阿希姆·绍尔（Joachim Sauer）
source

3

我真正想知道的是：为什么没有其他意见？我应该扮演魔鬼拥护者吗？毕竟，Apache Commons Collections并不是一个不错的库。

— Joachim Sauer，2009年

10

由于Apache缺少泛型，因此我认为很明显这两个是未来。Google是前进的下一个逻辑步骤。但是，它是由The Giant制造的，这是一种奇怪的感觉……但是，只要获得了免费许可，即使它是由Microsoft制造的，也没有关系。我猜。

— 乔纳斯·普拉卡

12

读者应该意识到，这是一个非常古老的答案，并且已经发生了很大的变化

— Roy Truelove 2014年

1

@RoyTruelove发生了很大变化，这并不让人感到惊讶，我很想听听您对此事的最新想法，或者链接到最近的评论/比较。我喜欢“默认情况下不可变/仅在需要时才可变”的理念，并且喜欢在番石榴中包含泛型，但是我一直在阅读的材料可能都已过时，就像您说此线程已成为事实一样。

— joeA 2014年

2

@ testerjoe2-对不起，我很久以前就写了那条评论，坦率地说不记得它的原因。事后看来，这是非常无益的！我没有意识到这些库自2010年以来就没有发生过变化，但是我确实知道它们仍在被大量使用，因此我认为应该是安全的。如果我今天开始一个新项目，那么我可能会仔细看看高盛（Goldman Sach）的收藏库：github.com/goldmansachs/gs-collections。当您是世界上最邪恶的公司之一时，您确实应该确保您拥有一个kickass java集合库。

— Roy Truelove

72

常见问题解答： Google收藏集常见问题解答

当Google可以尝试改善Apache Commons Collections时，为什么要构建所有这些呢？

很明显，Apache Commons Collections无法满足我们的需求。它不使用泛型，这对我们来说是个问题，因为我们讨厌从代码中获取编译警告。它也长期处于“持有模式”。我们可以看到，在我们乐意使用它之前，需要我们投入大量资金来修复它，同时，我们自己的图书馆已经开始有机增长。

Apache库与我们的库之间的重要区别在于，我们的集合非常忠实地遵守由它们实现的JDK接口指定的协定。查看Apache文档，您会发现无数违反示例。他们应该这么清楚地指出这些建议，但值得一提的是，偏离标准收款行为是有风险的！您必须小心处理此类集合；错误始终只是在等待发生。

我们的馆藏已完全泛化，并且从未违反其合同（有个别例外，JDK实现为可接受的违规树立了坚实的先例）。这意味着您可以将我们的集合之一传递给任何希望使用Collection的方法，并确信所有事情都将按预期运行。

— 戴维·康森尼
source

71

我发现最重要的事情使Google收藏集成为起点：

泛型（无泛型的集合-FTL）
与Collections框架的一致性（Josh Bloch是该框架的主要参与者）
正确性。这些家伙拼命地解决这个问题。它们具有25K单元测试之类的东西，并且与正确地设置API紧密相关。

这是主要作者在YouTube上录制的精彩演讲视频，他很好地讨论了有关该库的知识。

— 乔斯利切
source

7

视频链接+1

— Jesper

1

有关Google馆藏的更多详细信息，请阅读：javalobby.org/articles/google-collections（采访其主要创作者）。寻找问题“您的方法有什么独特之处？例如，它与Apache Commons Collection有何不同？”

— Jonik 2010年

4

Apache Commons Collections版本4使用泛型。commons.apache.org/proper/commons-collections/release_4_0.html

— 阿卜杜勒

-7

另外两件事（我希望我没错）

Guava的许可证（谷歌收藏的新名称）是Apache许可证2.0，意味着：与Apache Commons项目的许可证相同
我无法在要下载的文件中找到番石榴的源代码（似乎只能进行git-access）

— 奥利维尔·福乔（Olivier Faucheux）
source

19

来源？您的意思是可以在Eclipse中附加的jar？在这里。BTW：那怎么发生的git clone https://code.google.com/p/guava-libraries/和git checkout v11.0.2？

— Xaerxess 2012年

-7

关于Guava的一件令人讨厌的事情是Multimap不会扩展java.util.Map。如果您有自己的方法可以在Maps上使用，那么它们将无法在Guava Multimaps上使用（Apache MultiMap接口确实扩展了java.util.Map）。我敢肯定，这是有其道理的，但是也很不方便。

— 马特
source

16

如果要使用Multimaplike Map，则始终可以asMap()查看。

— Xaerxess 2012年

22

您如何期望Multimap实现java.util.Map？多重地图从根本上不同于地图。

— sleske 2012年

1

Multimap <K，V>扩展了Map <K，Collection <V >> ..我怀疑G虽然有充分的理由不使用Map作为超接口。

— 马特2012年

10

@lucek：如果您仔细阅读Javadoc Map并了解到每个引用V实际上都是a Collection<V>，那么我想您很快就会知道为什么它不是一个好的超级接口Multimap<K, V>。

— ruakh 2012年