问题描述
我们目前使用 apache 集合、字符串工具等.我需要决定是否应该从 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 2007 年开源，针对 Java 5，因此，Guava 极大地受益于 Java 5 的特性:generics、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-collections 常见问题解答，标题为Google 为什么要构建这一切，而 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、Ordering, ...) - 不变性(不可变集合、
CharMatcher、Joiner、Splitter、...) - 实现隐藏(
Predicates.xXx, ...) - 更喜欢组合而不是继承(
ForwardXXX集合) - 空检查
- 枚举单例模式
- 序列化代理
- 深思熟虑的命名约定
- 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
我可以花上几个小时来解释这些设计选择带来的优势(如果你愿意，请告诉我).问题是，这些模式不仅是为了展示"，它们还具有真正的价值: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(甚至是 Joshua Bloch，他现在在 Google 工作！).
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 限制为最有用的功能.他们知道一旦添加了一个功能就很难删除，并遵循 Joshua Bloch 关于 API 设计的座右铭:如有疑问，请忽略".此外，使用@Beta 注释允许他们测试一些设计选择而无需承诺特定的 API.
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.只需查看 MapMaker 查看简单"构建器中的强大功能.其他好的(虽然更简单?)示例是 CharMatcher, Splitter 和 订购.
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.
组合 Guava 的各个部分也很容易.例如，假设您要缓存复杂 函数?将此函数提供给您的 MapMaker 和 BINGO，您将获得一个线程安全的计算地图/缓存.需要将映射/函数输入限制为特定字符串吗?没问题，将它包装在 ConstrainedMap，使用 CharMatcher 拒绝不合适的字符串...
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...
虽然 Apache Commons 的开发似乎随着 Commons Lang 3.0 的工作而加速，但 Guava 似乎目前正在加速发展，而 Google 开源了更多的内部类.
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 在内部严重依赖它，我认为它不会很快消失.此外，开源其公共库允许 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 是我开始新项目时的首选库.我非常感谢 Google 和出色的 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:我(还)没有任何 Google 股票
这篇关于guava 和 apache 等效库之间有哪些重大改进?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！