回答:
第一に、javamonkey79が説明したように、Google GuavaとApache Commonsは同様の機能を共有していますが、どちらにも対応する機能がありません。したがって、ライブラリを1つだけに制限することは賢明ではない場合があります。
そうは言っても、私が選択しなければならない場合は、Guavaを使用することを選択し、Guavaに必要な機能がない（まれな）場合に備えてApache Commonsを維持します。その理由を説明しよう。
Apache Commonsは非常に成熟したライブラリですが、ほぼ10年前のものであり、Java 1.4をターゲットとしています。Guavaは2007年にオープンソースであり、Java 5をターゲットにしているため、Java 5の機能であるGenerics、varargs、enums、およびautoboxingから、Guavaに大きなメリットがあります。
グアバの開発者によると、ジェネリックは、Apache Commonsを改善する代わりに新しいライブラリを作成することを選択した理由の1つです（「GoogleがApacheを改善しようとしたのに、なぜGoogleがこれをすべて作成したのか」というタイトルでgoogle-collections FAQを参照してください。コモンズコレクションの代わりに？」）。
私はそれらに同意します：しばしば批判されます（具体化なし、下位互換性のために制限されます）が、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の過去の間違い（ただし、それらの間違いではない）から学びました。
グアバの設計者は、APIを最も有用な機能に制限して、あまりにも多くの機能を追加する誘惑に抵抗します。彼らは、一度追加された機能を削除するのが非常に難しいことを知っており、API設計に関するJoshua Blochのモットーである「疑わしい場合は、除外する」に従ってください。また、@ Betaアノテーションを使用すると、特定のAPIにコミットすることなく、いくつかの設計の選択をテストできます。
上記の設計の選択により、非常にコンパクトなAPIが可能になります。MapMakerを見るだけで、「シンプルな」ビルダーに組み込まれたパワーを確認できます。他の良い（とはいえ、単純ですか？）の例は、CharMatcher、Splitter、およびOrderingです。
グアバのさまざまな部分を構成することも非常に簡単です。たとえば、複雑な関数の結果をキャッシュしたいとしますか？この関数をMapMakerとBINGOにフィードすると、スレッドセーフなコンピューティングマップ/キャッシュが得られます。マップ/関数の入力を特定の文字列に制限する必要がありますか？問題ありません。これをConstrainedMap内にラップし、CharMatcherを使用して不適切な文字列を拒否します...
Apache Commonsの開発はCommons Lang 3.0での作業により加速しているようですが、グアバは現時点でさらに勢いを増しているようですが、Googleはより多くの内部クラスをオープンソース化しています。
Googleは内部で大きく依存しているので、すぐになくなることはないと思います。さらに、その共通ライブラリをオープンソース化することで、Googleはそれに依存する他のライブラリを（Guiceが現在行っているように再パッケージする代わりに）より簡単にオープンソース化できます。
上記のすべての理由から、Guavaは新しいプロジェクトを開始するときに頼りになるライブラリです。そして、私はグーグルとこの素晴らしいライブラリを作成した素晴らしいグアバ開発者にとても感謝しています。
PS：この他のSOの質問も読みたいかもしれません
PPS：私は（まだ）Google株を所有していません
2010年8月から、r06リリース以降、グアバを使用しています。基本的に、開発するためのグリーンフィールドJavaライブラリがあったので、J2SE APIに最適な付属ライブラリを探しました。従来、Apache Commonsライブラリを使用していましたが、そこに何があるのかを確認したくて、Guavaを使い始めました。
私にとって、GuavaはJavaを簡潔で表現力豊かなスクリプト言語に近づけるように感じさせます。
私の経験では、彼らが互いに争ったり、グアバがapache libsを改善しているとは思いません。むしろ、グアバはapache libsを補完します。グアバにはapacheにはないクラスやユーティリティがあり、その逆も同様です。
したがって、それ自体を切り替える必要があることはわかりません。「適切な作業に適切なツールを使用する」と言います。
Filesですか？ JDKを使用するにはFiles、パス全体を書き出す必要があります...）。私のアプリには多くのファイルユーティリティが必要だったので、この場合はApacheの使用を避けられませんでした。