Google Guava対Apache Commons [終了]

私はJavaで双方向のマップ実装を探していて、次の2つのライブラリに出くわしました。

• Google Guava（以前の「Googleコレクション」）
• Apache Commonsコレクション

どちらも無料で、私が探していた双方向マップ実装（ApacheのBidiMap、GoogleのBiMap）があり、驚くほどほぼ同じサイズです（Apache 493 kB、Google 499 kB）[ed .: no true true！]すべての点で私にかなり似ています。

どちらを選択する必要がありますか。その理由は何ですか。他に同等の代替案がありますか（無料で、少なくとも双方向マップが必要です）？私は最新のJava SEを使用しているため、Java 5などに人工的に制限する必要はありません。

私の意見では、より良い選択はGuava（以前はGoogleコレクションとして知られていました）です：

• より現代的です（ジェネリックがあります）
• コレクションAPIの要件に完全に従う
• 積極的に維持されている
• CacheBuilderそしてそれは前任者MapMakerはただ素晴らしかったです

Apache Commons Collectionも優れたライブラリですが、ジェネリック対応バージョンを提供することに長い間失敗しており（私の意見では、コレクションAPIの主な欠点です）、一般にメンテナンス中/実行しないようです。 -too-much-work-on-itモード_{最近、Commons Collectionsは再び}勢いを増しました_{が、それに追いつくために追いついています。}。

ダウンロードサイズ/メモリフットプリント/コードサイズが問題である場合、他のライブラリの一般的な依存関係であるため、Apache Commons Collectionの方が適している可能性があります。したがって、独自のコードでそれを使用することも、追加の依存関係を追加せずに実行できる可能性があります。編集：多くの新しいライブラリは実際にはApache Commons Collection ではなく Guavaに依存しているため、この「利点」は部分的に覆されています。

よくある質問から： Googleコレクションのよくある質問

代わりに、Apache Commons Collectionsを改善しようとした可能性があるのに、なぜGoogleはこれをすべて構築したのですか？

Apache Commons Collectionsは明らかに私たちのニーズを満たしていませんでした。これはジェネリックを使用しません。これは、コードからコンパイル警告を取得するのが嫌いなため、問題になります。それはまた、長い間「保持パターン」にありました。私たちがそれを使用して満足するまでそれを修正するために私たちからかなり大きな投資が必要であり、その間、私たち自身のライブラリーはすでに有機的に成長していることがわかりました。

Apacheライブラリと私たちのライブラリの重要な違いは、私たちのコレクションが、それらが実装するJDKインターフェースによって指定された規約に非常に忠実に準拠していることです。Apacheのドキュメントを確認すると、違反の例が無数にあります。彼らはこれらをはっきりと指摘していることで信用に値しますが、それでも、標準の収集動作から逸脱することは危険です！このようなコレクションをどう扱うかには注意が必要です。バグは常に発生するのを待っているだけです。

私たちのコレクションは完全に生成されており、契約に違反することはありません（JDKの実装が許容可能な違反の強力な先例を設定している孤立した例外を除きます）。これは、コレクションの1つを、コレクションを期待する任意のメソッドに渡すことができ、物事が正しく機能することを確信できることを意味します。

私が見つけた最も重要なことは、Googleコレクションを出発点にしています。

• ジェネリック（ジェネリックのないコレクション-FTL）
• コレクションフレームワークとの整合性（Josh Blochはこのフレームワークの主要なプレーヤーでした）
• 正当性。これらの人たちは、この問題を正すことに必死に結びついています。彼らは25Kのユニットテストのようなものを持っており、APIを適切に取得することに結びついています。

これは、主要な著者によって与えられた講演の素晴らしいYoutubeビデオです。彼は、このライブラリーについて知っておく価値のあることについてよく議論しています。

他に2つあります（私が間違っていないといいのですが）

• グアバのライセンス（グーグルコレクションの新しい名前）は、Apache License 2.0です。つまり、Apache Commonsプロジェクトと同じです。
• ダウンロードするファイルにGuavaのソースコードが見つかりません（gitアクセスしかできないようです）

Guavaの1つの厄介な点は、Multimapがjava.util.Mapを拡張しないことです。マップで機能する独自のメソッドがある場合、それらはGuavaマルチマップでは機能しません（Apache MultiMapインターフェースはjava.util.Mapを拡張します）。それがそうであるのにはいくつかの正当な理由があると私は確信していますが、それも不便です。