現在、Apache コレクション、文字列ユーティリティなどを使用しています。Apache Foundations 実装から切り替える必要があるかどうかを決定する必要があります。
重要な基準は、開発者の使いやすさです。パフォーマンスやメモリ使用量は、私たちにとってまだ重要な問題ではありません。現時点では、開発のスピードが重要な基準です。
guava によって開発者の生活がいかに大幅に楽になったかについてご意見をお聞かせください。
ベストアンサー1
まず、ジャバモンキー79説明したように、Google Guava と Apache Commons は類似した機能を共有していますが、どちらも相手側にはない機能を持っています。したがって、1 つのライブラリだけに限定するのは賢明ではないかもしれません。
そうは言っても、もし選択しなければならないとしたら、私は Guava を使い、Guava に必要な機能がない (まれな) 場合に備えて Apache Commons を残しておくことを選びます。その理由を説明してみたいと思います。
グアバはより「現代的」
Apache Commonsは非常に成熟したライブラリですが、10年近くも前のもので、Java 1.4を対象としています。Guavaは2007年にオープンソース化はJava 5をターゲットにしており、Guava は Java 5 の機能から大きな恩恵を受けています:ジェネリック、可変引数、列挙型、 そしてオートボクシング。
Guavaの開発者によると、ジェネリックはApache Commonsを改良するのではなく新しいライブラリを作成することを選択した理由の1つです（Google コレクションに関するよくある質問、タイトルの下に「Google は、Apache Commons Collections の改善を試みることもできたのに、なぜこれらすべてを構築したのでしょうか?」）。
私も同意します。Javaジェネリックは、よく批判されますが（具体化されていない、後方互換性のために制限されている）、とてもGuava のように適切に使用すると便利です。ジェネリック化されていないコレクションを扱うくらいなら、やめたほうがいいでしょう。
（Apache Commons 3.0では、する対象Java 1.5以上)
Guavaは非常によく設計され、文書化されています
コードには、API の読みやすさ、見つけやすさ、パフォーマンス、セキュリティ、スレッドセーフ性を向上させるためのベストプラクティスと便利なパターンが満載です。
読んで効果的なJava(ちなみに素晴らしい本です)、コードのいたるところにこれらのパターンが見られます:
- ファクトリメソッド（など
ImmutableList.copyOf()） - ビルダーパターン(
ImmutableList.builder()、、、、、、... )JoinerCharMatcherSplitterOrdering - 不変性 (不変コレクション、、、、
CharMatcher... )JoinerSplitter - 実装の非表示 (
Predicates.xXx、...) - 継承よりも構成を優先する（
ForwardXXXコレクション） - null チェック
- enum-singleton パターン
- シリアル化プロキシ
- よく考えられた命名規則
これらの設計上の選択によってもたらされる利点について、何時間でも説明できます (必要なら言ってください)。重要なのは、これらのパターンは「見せかけ」だけではなく、実際の価値があるということです。API は使いやすく、学習しやすく (ドキュメントが充実していることを忘れていましたか?)、効率性も高く、多くのクラスは不変性によりシンプルかつスレッドセーフです。
ボーナスポイントとして、コードを見ると多くのことが学べます :)
グアバは一貫している
Kevin Bourrillion (Guavaの主任開発者)は、ライブラリ全体にわたって高い品質と一貫性を維持する素晴らしい仕事をしています。もちろん彼だけではありません。素晴らしい開発者グアバに貢献した（ジョシュア・ブロック（現在は Google で働いています！）
Guavaの背後にあるコア哲学と設計選択はライブラリ全体で一貫しており、開発者はJDK APIの過去の失敗から学んだ非常に優れた（IMO）API設計原則に従っています（彼らのただし間違いもあります。
グアバはパワーウェイトレシオが高い
Guavaの設計者は、APIを最も有用なものに限定し、多くの機能を追加する誘惑に抵抗しています。彼らは、一度追加された機能を削除するのは非常に難しいことを知っており、Joshua Bloch の API 設計に関するモットー: 「疑わしい場合は、省略する」また、@Betaアノテーションを使用すると、特定のAPIにコミットせずにいくつかの設計上の選択肢をテストする。
上で述べた設計上の選択により、非常にコンパクトなAPIが実現しました。マップメーカー「シンプルな」ビルダーに詰め込まれたパワーを見る。他の良い（ただしよりシンプル？）例は、文字マッチング、スプリッター、 そして注文。
Guavaのさまざまな部分を構成するのも非常に簡単です。例えば、複雑な結果をキャッシュしたいとします。関数? この関数をMapMakerに入力すれば、スレッドセーフな計算マップ/キャッシュが完成します。マップ/関数の入力を特定の文字列に制限する必要がありますか? 問題ありません。制約マップ、 を使って文字マッチング不適切な文字列を拒否します...
グアバは活発に開発中
Apache Commons の開発は Commons Lang 3.0 の作業によって加速しているようですが、Guava は現時点ではより勢いを増しているようで、Google はより多くの内部クラスをオープンソース化しています。
Googleは社内でこれを大いに利用しているので、すぐになくなることはないと思います。さらに、共通ライブラリをオープンソース化することで、Googleはより簡単にオープンソース化できるようになります。他のそれに依存するライブラリ（再パッケージギースのように現在する）。
結論
上記の理由から、Guava は新しいプロジェクトを開始するときに私が頼りにするライブラリです。そして、この素晴らしいライブラリを作成した Google と素晴らしい Guava 開発者にとても感謝しています。
PS: こちらも読んでみてくださいこの他のSOの質問
PPS: 私はまだ Google 株を所有していません