首先，正如 javamonkey79所 解释的，尽管Google Guava和Apache
Commons确实具有相似的功能，但是它们都具有相对应的功能。因此，将自己限制为仅一个库可能是不明智的。

话虽这么说，但如果我不得不选择的话，我会选择使用Guava，在Guava没有所需功能的罕见情况下，请使用Apache Commons。让我尝试解释原因。

番石榴更“现代”

Apache Commons是一个非常成熟的库，但它也已有近10年的历史，并且针对Java 1.4。Guava
于2007年开源，目标是Java 5，因此 Guava极大地受益于Java 5功能： 泛型 ，
varargs ， 枚举 和 自动装箱 。

根据Guava开发人员的说法，泛型是他们选择创建新库而不是改进Apache Commons的原因之一（请参阅google-collections
FAQ，标题为
“为什么Google可能会尝试改进Apache，但为什么要构建所有这些库呢？改为使用Commons Collections？” ）。

我同意他们的观点：尽管经常受到批评（没有版本化，由于向后兼容性而受到限制），但Java泛型在适当使用时仍然 非常
有用，就像Guava一样。我宁愿退出，也不愿使用非通用的收藏夹！

（请注意，Apache Commons 3.0 确实 针对Java 1.5+）

番石榴是非常好的设计/记录

该代码充满了最佳实践和有用的模式，可以使API更具可读性，可发现性，高性能，安全性，线程安全性…

阅读了 有效的Java （很棒的书BTW），我在代码中到处都可以看到这些模式：

• 工厂方法（例如ImmutableList.copyOf()）
• 生成器模式（ImmutableList.builder()，Joiner，CharMatcher，Splitter，Ordering，…）
• 不变性（不变的集合，CharMatcher，Joiner，Splitter，…）
• 隐藏实现（Predicates.xXx，…）
• 偏重于继承而不是继承（ForwardXXX集合）
• 空检查
• 枚举-单子模式
• 序列化代理
• 深思熟虑的命名约定

我可以花几个小时解释这些设计选择带来的好处（如果需要，请告诉我）。事实是，这些模式不仅是“用于展示”，而且它们具有真正的价值：API易于使用，易于学习（我忘了说它的文档记录得很好吗？），效率更高，由于它们的不可变性，许多类更简单/线程安全的。

作为奖励，您可以通过查看代码来学习很多：)

番石榴是一致的

Kevin
Bourrillion（Guava的首席开发人员）在保持整个库的高质量/一致性方面做得很好。当然，他并不孤单，而且许多杰出的开发人员都为Guava做出了贡献（甚至是现在在Google工作的Joshua
Bloch！）。

在整个库中，Guava背后的核心理念和设计选择是一致的，并且开发人员遵循了非常好的（IMO）API设计原则，从过去的JDK API错误中吸取了教训（尽管不是
他们的 错误）。

番石榴的功率重量比高

Guava设计人员抵制了添加太多功能的诱惑，从而将API限制为最有用的功能。他们知道很难删除添加的功能，并遵循Joshua
Bloch关于API设计的座右铭：“如有疑问，请不要使用”。同样，使用@Beta批注使他们可以测试某些设计选择，而无需提交特定的API。

上面提到的设计选择允许使用非常紧凑的API。只需查看MapMaker即可查看“简单”构建器中包含的功能。其他好的（尽管更简单？）示例是CharMatcher，Splitter和Ordering。

组成番石榴的各个部分也非常容易。例如，假设您要缓存复杂函数的结果？将此功能提供给MapMaker和BINGO，即可获得线程安全的计算地图/缓存。是否需要将map
/
function输入限制为特定的String？没问题，将其包装在ConstrainedMap中，使用CharMatcher拒绝不适当的字符串…

番石榴正在积极发展中

尽管随着Commons Lang 3.0的开发，Apache
Commons的开发似乎有所加速，但Guava似乎正在加速发展，而Google则开放了更多内部类的资源。

由于Google内部高度依赖它，因此我认为它不会很快消失。另外，通过开源其通用库，Google可以更轻松地开源 其他
依赖于它的库（而不是像Guice当前所做的那样重新打包）。

结论

由于上述所有原因，Guava是我开始新项目时的首选库。非常感谢Google和创建了这个出色库的Guava开发人员。