guava 和 apache 等效库之间有哪些重大改进？
我们目前使用 apache 集合、字符串实用程序等。我需要决定是否应该从 apache 基础实现切换。
重要的标准是开发人员使用的便利性。性能/内存使用对我们来说还不是一个重要问题。发展速度是此时的关键标准。
我很感激有关番石榴如何让开发人员的生活变得更加轻松的意见。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
首先，正如 javamonkey79 所解释的，虽然 Google Guava 和 Apache Commons 确实具有相似的功能，但它们也都具有其对应版本所没有的功能。因此，将自己限制在一个库中可能是不明智的。
话虽这么说，如果我必须选择，我会选择使用 Guava，并在 Guava 不具备所需功能的（罕见）情况下保留 Apache Commons。让我尝试解释一下原因。
Guava 更“现代”
Apache Commons 是一个非常成熟的库，但它也已经有近 10 年历史了，并且面向 Java 1.4。 Guava 于 2007 年开源，面向 Java 5，因此，Guava 极大地受益于 Java 5 功能：泛型、varargs、枚举和自动装箱 。
根据 Guava 开发人员的说法，泛型是他们选择创建新库而不是改进 Apache Commons 的原因之一（请参阅 google-collections 常见问题解答，标题为“Google 为什么要构建这一切，而它本可以尝试改进 Apache Commons Collections？”）。
我同意他们的观点：虽然经常受到批评（没有具体化，由于向后兼容性而受到限制），但如果使用得当，Java 泛型仍然非常有用，就像 Guava 一样。我宁愿退出也不愿使用非通用集合！
（请注意，Apache Commons 3.0，确实针对 Java 1.5+）
Guava 的设计/文档非常好。
代码充满了最佳实践和有用的模式，使 API 更具可读性、可发现、高性能、安全、线程安全...
读过《Effective Java》（顺便说一句，这是一本很棒的书），我在代码中随处可见这些模式：
ImmutableList.builder()、Joiner、CharMatcher、Splitter、Ordering，...）CharMatcher，Joiner，Splitter，...）Predicates.xXx, ...)ForwardXXX集合）我可以继续花几个小时解释这些设计选择带来的优势（如果您愿意请告诉我）。事实是，这些模式不仅仅是“为了展示”，它们具有真正的价值：API 使用起来很愉快，更容易学习（我是否忘记说它的文档有多完善？），更高效，并且许多类由于其不变性而更简单/线程安全。
作为一个奖励点，通过查看代码可以学到很多东西:)
Guava 是一致的
Kevin Bourrillion（Guava 的首席开发人员）在保持整个库的高水平质量/一致性方面做得很好。当然，他并不孤单，许多优秀的开发人员都做出了贡献Guava（甚至是 Joshua Bloch，他现在在 Google 工作！）。
Guava 背后的核心理念和设计选择在整个库中是一致的，并且开发人员坚持非常好的 (IMO) API 设计原则，并从 JDK API 过去的错误中吸取了教训（尽管不是他们的错误） ）。
Guava 具有高功率重量比
Guava 设计者抵制添加太多功能的诱惑，将 API 限制为最有用的功能。他们知道功能一旦添加就很难删除，因此遵循 Joshua Bloch 关于 API 设计的座右铭： “如有疑问，请将其排除”。此外，使用 @Beta 注释可以让他们测试一些设计选择，而无需承诺特定的 API。
上面提到的设计选择允许非常紧凑的 API。只需查看 MapMaker 查看“简单”构建器中包含的功能。其他好的（虽然更简单？）示例是 CharMatcher，分割器和订购。
组合 Guava 的各个部分也非常容易。例如，假设您要缓存复杂 函数？将此函数输入到您的 MapMaker 和 BINGO，您就得到了一个线程安全的计算地图/缓存。需要将映射/函数输入限制为特定字符串？没问题，将其包装在 内ConstrainedMap，使用 CharMatcher 拒绝不适当的字符串...
Guava 正在积极开发中
虽然 Apache Commons 的开发似乎随着 Commons Lang 3.0 的工作而加速，但 Guava 目前似乎获得了更多动力，而 Google 则开放获取更多内部类的资源。
由于谷歌内部严重依赖它，我认为它不会很快消失。另外，开源其公共库使 Google 能够更轻松地开源依赖于它的其他库（而不是重新打包它们，就像目前的 Guice 确实）。
结论
由于上述所有原因，Guava 是我开始新项目时的首选库。我非常感谢 Google 和出色的 Guava 开发人员，他们创建了这个出色的库。
PS：您可能还想阅读这个其他问题 >
PPS：我还没有持有任何 Google 股票
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.
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.
Guava is more "modern"
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.
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?").
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!
(Note that Apache Commons 3.0, does target Java 1.5+)
Guava is very well designed / documented
The code is full of best practices and useful patterns to make the API more readable, discoverable, performant, secure, thread-safe...
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, ...)ForwardXXXcollections)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 :)
Guava is consistent
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!).
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 has a high power-to-weight ratio
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.
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.
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...
Guava is in active development
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.
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).
Conclusion
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: you might also want to read this other SO question
PPS: I don't own any Google stock (yet)
我从 2010 年 8 月开始使用 guava，从 r06 版本开始。基本上，我有一个新的 java 库需要开发，所以我四处寻找 J2SE API 的最佳辅助库。传统上，我们使用 Apache Commons 库，但我想看看那里有什么，并开始使用 Guava。
优点
缺点
对我来说，Guava 让 Java 感觉更接近一种简洁、富有表现力的脚本语言，这很棒。
I've been using guava since Aug 2010, starting with the r06 release. Basically, I had a greenfield java library to develop, so I looked around for the best adjunct library for the J2SE API. Traditionally, we'd used the Apache Commons libraries, but I wanted to see what was out there and began using Guava.
Pros
Cons
To me, Guava makes Java feel closer to a terse, expressive scripting language, and that's great.
根据我的经验，我不认为它们相互竞争，也不认为 guava 对 apache 库进行了改进。相反，guava 补充 apache 库。 guava 中有一些 apache 中没有的类和实用程序，反之亦然。
因此，我不知道您本身是否需要切换 - 我会说“使用正确的工具来做正确的工作”。
In my experience I don't perceive that they contend with one another, or that guava improves on the apache libs. Rather, guava complements the apache libs. There are classes and utilities in guava that are not in apache and vice versa.
Therefore, I don't know that you need to switch per se - I would say "use the right tool for the right job".