Google Guava vs. Apache Commons

作者: 小它．Little it
发布时间: 2024-03-11 12:51:10 (1月前)
转自：

6 条回复

0#
回复此人
清月 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我发现最重要的事情是让Google Collections成为开始的地方： </p> <UL> <LI> 泛型（没有泛型的集合 - FTL） </LI> <LI> 与馆藏框架保持一致（Josh Bloch是此框架中的关键人物） </LI> <LI> 正确性。这些家伙迫切想要解决这个问题;他们有类似25K单元测试的东西，并且与使API恰到好处有关。 </LI> </UL> <P> 这是一个伟大的 <a href="http://www.youtube.com/watch?v=ZeO_J2OcHYM" rel="noreferrer"> Youtube视频 </A> 主要作者给出的一个演讲，他很好地讨论了这个图书馆值得了解的内容。 </p> </DIV>

编辑
1#
回复此人
易米烊光 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 来自常见问题： <a href="http://code.google.com/p/google-collections/wiki/Faq" rel="nofollow noreferrer"> Google Collections常见问题解答 </A> </p> <BLOCKQUOTE> <P> 的<strong> 谷歌为什么要构建所有这些，当它可能试图改进Apache Commons Collections时呢？ </强> </p> <P> Apache Commons Collections非常清楚地无法满足我们的需求。它不使用泛型，这对我们来说是一个问题，因为我们讨厌得到我们的代码中的编译警告。它也一直在“持有模式“很长一段时间。我们可以看到它需要一个漂亮的我们的主要投资来解决它，直到我们乐意使用它，与此同时，我们自己的图书馆已经有机地发展。 </p> <P> Apache库和我们的库之间的一个重要区别是我们的藏品非常忠实地遵守了指定的合同他们实现的JDK接口。如果你查看Apache 文档，你会发现无数的违规行为。他们值得赞扬的是指出这些如此清楚，但仍然偏离从标准的收集行为是有风险的！你一定要小心你做这样的收藏;错误总是等待发生。 </p> <P> 我们的产品系列完全一致，永远不会违反合同（有一些孤立的例外，JDK实现设置强大可接受的违法行为的先例）。这意味着你可以通过其中一个我们的集合到任何期望Collection和感觉的方法非常有信心，事情会完全按照自己的意愿运作。 </p> </BLOCKQUOTE> </DIV>

编辑
2#
回复此人
无语 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 关于Guava的一个令人讨厌的事情是Multimap不扩展java.util.Map。如果您有自己的方法可以在Maps上工作，那么它们将无法在Guava Multimaps上运行（Apache MultiMap接口确实扩展了java.util.Map）。我确信它有一个很好的理由，为什么它的方式，但它也不方便。 </p> </DIV>

编辑
3#
回复此人
解天 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 另外两件事（我希望我没错） </p> <UL> <LI> Guava（google集合的新名称）的许可证是Apache License 2.0，意思是：与Apache Commons项目相同 </LI> <LI> 我无法在要下载的文件中找到Guava的源代码（似乎只有git-access是可能的） </LI> </UL> </DIV>

编辑
4#
回复此人
易米烊光 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 在我看来，更好的选择是 <a href="https://github.com/google/guava" rel="noreferrer"> 的<strong> 番石榴 </强> </A> （以前称为Google收藏）： </p> <UL> <LI> 它更现代（有泛型） </LI> <LI> 它完全遵循Collections API要求 </LI> <LI> 它是积极维护的 </LI> <LI> <a href="https://google.github.io/guava/releases/snapshot/api/docs/com/google/common/cache/CacheBuilder.html" rel="noreferrer"> <code> CacheBuilder </code> </A> 它是它的前身 <a href="https://google.github.io/guava/releases/snapshot/api/docs/com/google/common/collect/MapMaker.html" rel="noreferrer"> <code> MapMaker </code> </A> 简直太棒了 </LI> </UL> <P> Apache Commons Collections也是一个很好的库，但它长期以来未能提供一个支持泛型的版本（这是一个 <EM> 重大的 </EM> 在我看来，收集API的缺点）并且通常似乎是在维护/不做太多工作的模式 <子> 最近Commons Collections再次获得了一些动力，但它有一些赶上来做。 </子> 。 </p> <P> 如果下载大小/内存占用/代码大小是一个问题，那么Apache Commons Collections可能是更好的候选者，因为它是其他库的常见依赖。因此，在您自己的代码中使用它也可以在不添加任何其他依赖项的情况下完成。编辑：这个特殊的“优势”现在被部分颠覆，因为许多新的库实际上依赖于番石榴和 <EM> 不 </EM> 在Apache Commons Collections上。 </p> </DIV>

编辑

登录后才能参与评论