Google Guava vs. Apache Commons [关闭]

Posted 2023-02-25

【中文标题】Google Guava vs. Apache Commons [关闭]

【英文标题】：Google Guava vs. Apache Commons [closed]

【发布时间】：2010-11-29 11:43:57

【问题描述】：

我正在寻找 Java 中的 bidirectional map 实现，偶然发现了这两个库：

Google Guava（以前称为“Google 收藏”） Apache Commons Collections

两者都是免费的，具有我正在寻找的双向地图实现（Apache 中的 BidiMap，Google 中的 BiMap），大小惊人地几乎相同（Apache 493 kB，Google 499 kB）[编辑：不再正确！ ] 并且在各方面都与我非常相似。

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

【问题讨论】：

您确定应该给我们选择图书馆的标准吗？许可、性能、附加依赖项、支持泛型、...

Google 收藏集在 repo1.maven.org 上可用：repo1.maven.org/maven2/com/google/collections/…

我的立场是正确的——我正在查看 com/googlecode

【参考方案1】：

来自常见问题： Google Collections FAQ

Google 本来可以尝试改进 Apache Commons Collections，但为什么要构建这一切？

Apache Commons Collections 显然不能满足我们的需求。它 不使用泛型，这对我们来说是个问题，因为我们讨厌得到 来自我们代码的编译警告。也曾被“捧 模式”很长一段时间。我们可以看到它需要一个漂亮的 我们进行了大量投资来修复它，直到我们乐于使用它， 与此同时，我们自己的图书馆已经在有机地发展。

Apache 库和我们的库之间的一个重要区别是 我们的系列非常忠实地遵守由指定的合同 他们实现的JDK接口。如果您查看 Apache 文档中，您会发现无数违规示例。他们 值得称赞的是，如此清楚地指出了这些，但仍然存在偏差 从标准收集行为是有风险的！你必须小心什么 你用这样的集合做；错误总是在等待发生。

我们的系列是完全通用的，从不违反他们的合同 （除了个别例外，JDK 实现设置了强大的 可接受的违规行为的先例）。这意味着您可以通过其中之一 我们的集合到任何期望集合和感觉的方法 非常有信心事情会完全按照应有的方式进行。

【参考方案2】：

在我看来更好的选择是Guava（以前称为谷歌收藏）：

它更现代（具有泛型） 它完全符合 Collections API 要求 积极维护 CacheBuilder 和它的前身 MapMaker 简直太棒了

Apache Commons Collections 也是一个不错的库，但它长期以来一直未能提供支持泛型的版本（在我看来，这是一个集合 API 的主要缺点）并且通常似乎处于维护/不要做太多工作的模式_{最近 Commons Collections 再次获得了一些动力，但它还有一些工作要做。}。。 p>

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

【讨论】：

我真正想知道的是：为什么没有其他意见？我应该扮演魔鬼代言人吗？毕竟，Apache Commons Collections 不是一个糟糕的库。

由于 Apache 缺少泛型，我认为这两者中的哪一个是未来是显而易见的。谷歌是向前迈出的下一个合乎逻辑的步骤。不过，这是一种奇怪的感觉，它是由 The Giant 构建的……但只要它是在免费许可下，即使它是由 Microsoft 构建的也无所谓。我猜。

读者应该知道这是一个非常老的答案，而且已经发生了很大的变化

@RoyTruelove 变化如此之大并不让我感到惊讶，我很想听听您目前对此事的看法，或者可能是最近评论/比较的链接。我喜欢“默认情况下不可变/仅在需要时才可变”的理念以及在番石榴中包含泛型，但我一直在阅读的材料可能都已经过时了，就像你说的那样。

@testerjoe2 - 抱歉，我很久以前写过那条评论，坦率地说，我不记得它的原因了。事后看来，这是一个非常无益的！我没有意识到这些库自 2010 年以来没有改变，但我知道它们继续被大量使用，所以我想说应该是安全的。如果我今天开始一个新项目，我可能会仔细看看高盛的收藏库：github.com/goldmansachs/gs-collections。当你是世界上最邪恶的公司之一时，你真的应该确保你有一个很棒的 Java 集合库。

【参考方案3】：

我发现让 Google 收藏成为开始的最重要的事情：

泛型（没有泛型的集合 -- FTL） 与 Collections 框架的一致性（Josh Bloch 是该框架的关键参与者） 正确性。这些人迫切需要解决这个问题。他们有类似 25K 的单元测试，并且与正确使用 API 息息相关。

这是主要作者的精彩演讲Youtube video，他很好地讨论了有关此库的值得了解的内容。

【讨论】：

关于 Google 收藏的精彩进一步阅读：javalobby.org/articles/google-collections（对其主要创作者的采访）。寻找问题“您的方法有什么独特之处？它与例如 Apache Commons Collection 有何不同？”

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

【参考方案4】：

关于 Guava 的一个令人讨厌的事情是 Multimap 没有扩展 java.util.Map。如果您有自己的适用于 Maps 的方法，它们将不适用于 Guava Multimaps（Apache MultiMap 接口确实扩展了 java.util.Map）。我敢肯定这是有原因的，但它也很不方便。

【讨论】：

如果你想像Map一样使用Multimap，总有asMap()视图。

您希望 Multimap 如何实现 java.util.Map？多地图与地图根本不同。

Multimap extends Map>.. 我怀疑 G 有充分的理由不使用 Map 作为超级接口。

@lucek：如果您查看Map 的Javadoc，并了解每个对V 的引用实际上都是Collection<V>，我想您很快就会明白为什么会这样Multimap<K, V> 不是一个好的超级接口。

【参考方案5】：

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

Guava（谷歌收藏的新名称）的许可证是 Apache License 2.0，意思是：与 Apache Commons 项目的许可证相同 我在要下载的文件中找不到 Guava 的源代码（似乎只有 git-access 是可能的）

【讨论】：

来源？你的意思是可以在Eclipse中附加的jar？ It's here。顺便说一句：git clone https://code.google.com/p/guava-libraries/ 和 git checkout v11.0.2 有什么问题？