问题描述
我们目前使用apache集合，字符串utils等。我需要决定是否应该从apache基础实现切换。
We currently use apache collections, string utils, etc. I need to decide if we should switch from the apache foundations implementation.
重要的标准是开发人员的易用性使用。性能/内存使用对我们来说不是一个重要问题。发展速度是目前的关键标准。
The important criteria is ease of developers use. Performance/memory usage is not yet an important issue for us. Speed of development is the key criteria at this point.
我很欣赏有关番石榴开发人员生活如何变得容易的意见。
I would appreciate opinions about how the developer's life became significantly easier with guava.
推荐答案
首先，正如 javamonkey79 所解释的那样，虽然Google Guava和Apache Commons确实共享相似的功能，但它们都具有不存在的功能他们的对手。因此，仅限于一个库可能是不明智的。
First of, as javamonkey79 explained, while Google Guava and Apache Commons do share similar features, they also both have functionality that is absent from their counterpart. Thus, limiting yourself to only one library might be unwise.
话虽如此，如果我必须选择，我会选择使用Guava，保持Apache Commons （罕见）Guava没有所需功能的情况。让我试着解释一下原因。
That being said, if I had to choose, I'd opt to use Guava, keeping Apache Commons around for the (rare) cases where Guava does not have the needed functionality. Let me attempt to explain why.
Apache Commons是一个非常成熟的图书馆，但它也差不多10年了，目标是Java 1.4。 Guava是，目标是Java 5，因此 Guava从Java 5功能中受益匪浅：泛型， varargs ， enums 和 autoboxing 。
Apache Commons is a really mature library, but it's also almost 10 years old, and targets Java 1.4. Guava was open sourced in 2007, targets Java 5, and thus Guava greatly benefits from the Java 5 features: generics, varargs, enums, and autoboxing.
根据Guava开发人员的说法，泛型是他们选择创建新库而不是改进Apache Commons的一个原因（参见，标题为为什么Google会构建所有这些，当时它可能试图改进Apache Commons Collections？）。
According to the Guava developers, generics are one reason they chose to create a new library instead of improving Apache Commons (see the google-collections FAQ, under the title "Why did Google build all this, when it could have tried to improve the Apache Commons Collections instead?").
我同意他们：虽然经常受到批评（没有具体化，但由于落后而受到限制兼容性），Java适配器仍然非常在适当使用时非常有用，就像Guava一样。我宁愿放弃而不是使用非泛化的集合！
I agree with them: while often criticized (no reification, limited due to backward compatibility), Java generics are still very useful when used appropriately, like Guava does. I'd rather quit than work with non-generified collections!
（注意Apache Commons 3.0， 目标Java 1.5+ ）
(Note that Apache Commons 3.0, does target Java 1.5+)
该代码充满了最佳实践和有用的模式使API更具可读性，可发现性，高性能，安全性，线程安全性......
The code is full of best practices and useful patterns to make the API more readable, discoverable, performant, secure, thread-safe...
阅读 Effective Java （很棒的书）顺便说一下，我在代码中到处都看到这些模式：
Having read Effective Java (awesome book BTW), I see these patterns everywhere in the code:
- 工厂方法（例如
ImmutableList.copyOf（）） - 构建器模式（
ImmutableList.builder（），Joiner，CharMatcher，Splitter，订购，...） - immutability（不可变集合，
CharMatcher，Joiner，Splitter，...） - 实施隐藏（
Predicates.xXx，...） - 赞成合成而不是继承（th e
ForwardXXX集合） - null-checks
- enum-singleton pattern
- 序列化代理
- 深思熟虑的命名惯例
- factory methods (such as
ImmutableList.copyOf()) - builder pattern (
ImmutableList.builder(),Joiner,CharMatcher,Splitter,Ordering, ...) - immutability (immutable collections,
CharMatcher,Joiner,Splitter,...) - implementation hiding (
Predicates.xXx, ...) - favoring composition over inheritance(the
ForwardXXXcollections) - null-checks
- enum-singleton pattern
- serialization proxies
- well thought-out naming conventions
I可以持续数小时解释这些设计选择带来的好处（告诉我你是否想要我）。问题是，这些模式不仅仅是为了节目，它们还有一个真正的价值：API是一种使用的乐趣，更容易学习（我忘了说它有多少记录？），更有效，以及由于它们的不变性，许多类更简单/线程安全。
I could go on for hours explaining the advantages brought by these design choices (tell me if you want me to). The thing is, these patterns are not only "for the show", they have a real value: the API is a pleasure to use, easier to learn (did I forget to say how well documented it is?), more efficient, and many classes are simpler / thread-safe due to their immutability.
作为奖励点，通过查看代码可以学到很多东西：）
As a bonus point, one learns a lot by looking at the code :)
Kevin Bourrillion（Guava的首席开发人员）在整个图书馆保持高水平的质量/一致性方面做得很好。他当然并不孤单，很多都做出了贡献到Guava（甚至，现在在谷歌工作！）。
Kevin Bourrillion (Guava's lead developer) does a great job maintaining a high level of quality / consistency across the library. He is of course not alone, and a lot of great developers have contributed to Guava (even Joshua Bloch, who now works at Google!).
Guava背后的核心理念和设计选择在整个库中是一致的，开发人员遵循非常好的（IMO）API设计原则，从过去的JDK API错误中学习（不是他们的错误，但是）。
The core philosophies and design choices behind Guava are consistent across the library, and the developers adhere to very good (IMO) API design principles, having learned from past mistakes of the JDK APIs (not their mistakes, though).
Guava设计师抵制了添加太多功能的诱惑，将API限制为最有用的功能。他们知道添加后删除功能非常困难，并遵循。此外，使用@Beta注释允许他们。
The Guava designers resist the temptation to add too many features, limiting the API to the most useful ones. They know it's very hard to remove a feature once added, and follow Joshua Bloch's motto on API design: "When in doubt, leave it out". Also, using the @Beta annotation allows them to test some design choices without committing to a specific API.
上面提到的设计选择允许非常紧凑的API。只需查看查看简单构建器内部的电源。其他好的（虽然更简单？）示例是，，。
The design choices mentioned above allow for a very compact API. Simply look at the MapMaker to see the power packed inside a "simple" builder. Other good (albeit simpler?) examples are CharMatcher, Splitter, and Ordering.
组成番石榴的各个部分也很容易。例如，假设您要缓存复杂结果？将此功能提供给MapMaker和BINGO，您就拥有了一个线程安全的计算映射/缓存。需要将地图/函数输入约束到特定的字符串？没问题，请将其包装在，使用拒绝不合适的字符串...
It's also very easy to compose various parts of Guava. For example, say you want to cache the result of a complex function? Feed this function to your MapMaker and BINGO, you got a thread-safe computing map/cache. Need to constrain the map/function inputs to specific Strings? No problem, wrap it inside a ConstrainedMap, using a CharMatcher to reject inappropriate Strings...
随着Commons Lang 3.0的开发，Apache Commons的开发速度似乎已经加快，Guava目前似乎有了更多的动力，而谷歌开源的内容更多。
While the development of Apache Commons seems to have accelerated with the work on Commons Lang 3.0, Guava seems to pick up more steam at the moment, while Google open sources more of their internal classes.
由于谷歌在内部严重依赖它，我认为它不会很快消失。此外，开源其公共库使Google可以更轻松地开源依赖它的其他库（而不是，就像Guice目前一样）。
Since Google heavily relies on it internally, I don't think it's going to disappear any time soon. Plus, open sourcing its common libraries allows Google to more easily open source other libraries that depend on it (instead of repackaging them, like Guice currently does).
对于以上所有原因，Guava是我开始一个新项目的首选图书馆。我非常感谢谷歌和那些创造了这个梦幻般的图书馆的真棒Guava开发者。
For all the above reasons, Guava is my go-to library when starting a new project. And I am very grateful to Google and to the awesome Guava developers, who created this fantastic library.
PS ：您可能还想阅读
PPS：我还没有任何谷歌股票
这篇关于guava和apache等价库之间有哪些重大改进？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！