Java Google Guava 与 Apache Commons
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1444437/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Google Guava vs. Apache Commons
提问by Joonas Pulakka
I was looking for a bidirectional mapimplementation in Java, and stumbled upon these two libraries:
我正在寻找Java 中的双向映射实现，并偶然发现了这两个库：
- Google Guava(formerly "Google Collections")
- Apache Commons Collections
- Google Guava（以前的“Google Collections”）
- Apache Commons 集合
Both are free, have the bidirectional map implementation that I was looking for (BidiMap in Apache, BiMap in Google), are amazingly nearly the same size (Apache 493 kB, Google 499 kB) [ed.: no longer true!] and seem in all ways pretty similar to me.
两者都是免费的，具有我正在寻找的双向地图实现（Apache 中的 BidiMap，Google 中的 BiMap），大小几乎相同（Apache 493 kB，Google 499 kB）[编辑：不再正确！] 并且似乎在所有方面都与我非常相似。
Which one should I choose, and why? Are there some other equivalent alternatives (must be free and have at least the bidirectional map)? I'm working with the latest Java SE, so no need to artificially limit to Java 5 or anything like that.
我应该选择哪一个，为什么？是否有其他等效的替代方案（必须是免费的并且至少有双向地图）？我正在使用最新的 Java SE，所以不需要人为地限制到 Java 5 或类似的东西。
采纳答案by Joachim Sauer
In my opinion the better choice is Guava(formerly known as Google collections):
在我看来，更好的选择是Guava（以前称为 Google 集合）：
- it's more modern (has generics)
- it absolutely follows the Collections API requirements
- it's actively maintained
CacheBuilderand it's predecessorMapMakerare just plain awesome
- 它更现代（有泛型）
- 它绝对遵循 Collections API 要求
- 它被积极维护
CacheBuilder它的前身MapMaker简直太棒了
Apache Commons Collections is a good library as well, but it has long failed to provide a generics-enabled version (which is a majordrawback for a collections API in my opinion) and generally seems to be in a maintenance/don't-do-too-much-work-on-it mode Recently Commons Collections has picked up some steam again, but it has some catching up to do..
Apache Commons Collections 也是一个很好的库，但它长期以来一直未能提供支持泛型的版本（在我看来，这是集合 API 的一个主要缺点）并且通常似乎处于维护/不做的状态- 太多的工作模式最近 Commons Collections 再次获得了一些动力，但它还有一些工作要做。.
If download size/memory footprint/code size is an issue then Apache Commons Collections might be a better candidate, since it is a common dependency of other libraries. Therefore using it in your own code as well could potentially be done without adding any additional dependencies. Edit: This particular "advantage" has been partially subverted by now, since many new libraries actually depend on Guava and noton Apache Commons Collections.
如果下载大小/内存占用/代码大小是一个问题，那么 Apache Commons Collections 可能是更好的候选者，因为它是其他库的常见依赖项。因此，在您自己的代码中使用它也可能无需添加任何额外的依赖项。编辑：这个特殊的“优势”现在已经被部分颠覆，因为许多新库实际上依赖于 Guava 而不是Apache Commons Collections。
回答by joeslice
The most important things I've found that make Google Collections the place to start:
我发现让 Google Collections 成为起点的最重要的事情：
- Generics (Collections without Generics -- FTL)
- Consistency with Collections framework (Josh Bloch was a key player in this framework)
- Correctness. These guys are desperately tied to getting this problem right; they have something like 25K unit tests, and are tied to getting the API just right.
- 泛型（没有泛型的集合——FTL）
- 与 Collections 框架的一致性（Josh Bloch 是该框架的关键参与者）
- 正确性。这些人拼命地解决这个问题；他们有类似 25K 的单元测试，并且与让 API 恰到好处有关。
Here's a great Youtube videoof a talk that was given by the primary author and he does a good job of discussing what is worth knowing about this library.
回答by Davide Consonni
From the faq: Google Collections FAQ
来自常见问题解答： Google Collections 常见问题解答
Why did Google build all this, when it could have tried to improve the Apache Commons Collections instead?
The Apache Commons Collections very clearly did not meet our needs. It does not use generics, which is a problem for us as we hate to get compilation warnings from our code. It has also been in a "holding pattern" for a long time. We could see that it would require a pretty major investment from us to fix it up until we were happy to use it, and in the meantime, our own library was already growing organically.
An important difference between the Apache library and ours is that our collections very faithfully adhere to the contracts specified by the JDK interfaces they implement. If you review the Apache documentation, you'll find countless examples of violations. They deserve credit for pointing these out so clearly, but still, deviating from standard collection behavior is risky! You must be careful what you do with such a collection; bugs are always just waiting to happen.
Our collections are fully generified and never violate their contracts (with isolated exceptions, where JDK implementations have set a strong precedent for acceptable violations). This means you can pass one of our collections to any method that expects a Collection and feel pretty confident that things will work exactly as they should.
当 Google 本来可以尝试改进 Apache Commons Collections 时，为什么要构建这一切？
Apache Commons Collections 显然不能满足我们的需求。它不使用泛型，这对我们来说是一个问题，因为我们讨厌从我们的代码中获得编译警告。它也长期处于“持有模式”。我们可以看到，在我们乐于使用它之前，它需要我们进行大量投资才能修复它，与此同时，我们自己的图书馆已经在有机地增长。
Apache 库和我们的库之间的一个重要区别是，我们的集合非常忠实地遵守它们实现的 JDK 接口指定的契约。如果您查看 Apache 文档，您会发现无数违规示例。他们如此清楚地指出这些问题值得称赞，但是，偏离标准的收集行为仍然是有风险的！你必须小心处理这样的集合；错误总是等待发生。
我们的集合是完全通用的，从不违反他们的合同（除了孤立的例外，JDK 实现为可接受的违规行为树立了一个强有力的先例）。这意味着您可以将我们的一个集合传递给任何需要集合的方法，并且非常确信事情会完全按预期工作。
回答by Olivier Faucheux
Two other things (I hope I'm not wrong)
另外两件事（我希望我没有错）
- The licence of Guava (new name for google collections) is the Apache License 2.0, meaning: the same one as for Apache Commons project
- I cannot find the source code of Guava in a file to download (it seems only a git-access is possible)
- Guava（google collections 的新名称）的许可证是 Apache License 2.0，意思是：与 Apache Commons 项目相同
- 我在要下载的文件中找不到 Guava 的源代码（似乎只有 git-access 是可能的）
回答by matt
One nasty thing about Guava is that Multimap does not extend java.util.Map. If You have Your own methods that work on Maps they won't work on Guava Multimaps (Apache MultiMap interface does extend java.util.Map). I'm sure that there's some good reason why it's the way it's but it's also inconvenient.
Guava 的一件令人讨厌的事情是 Multimap 没有扩展 java.util.Map。如果您有自己的适用于 Maps 的方法，它们将不适用于 Guava Multimaps（Apache MultiMap 接口确实扩展了 java.util.Map）。我相信有一些很好的理由为什么它是这样的，但它也很不方便。
