SpringとDaggerを持っているのに、なぜGuiceを使用/開発するのですか？
私の知る限り、Daggerはコードを生成しますが、GuiceとSpringはランタイム処理に依存するため、Daggerはより高速に動作しますが、プログラマー側でより多くの作業が必要です。パフォーマンスEdgeにより、モバイル（Android）開発に適しています。
ただし、GuiceとSpringを残した場合、後者には多くの統合があります。 Spring Frameworkを使用できる場合、Guiceの開発/使用のポイントは何ですか（基本的に同じことをしますが、データベースアクセスが簡単になります）。
Googleは、Spring Frameworkを使用する（おそらく貢献する）のではなく、独自のDIツールを作成して車輪を再発明しようとしないのですか？
DIツールの選択をガイドする決定ツリーを探しています。
DaggerはGuiceの後に、Squareに移動したGuiceの作成者（ "Crazy Bob" Lee ）によって作成されたことを認識することが重要です。
- Springは当初 2002年10月 でリリースされました。
- Googleは最初にGuiceを 2007年3月 で公開しました。
- JSR-3 正式な
javax.inject注釈 October 2009 、Google（Bob Lee）、Spring、およびその他の業界プレーヤーからの大量の入力。 - Squareは当初、Dagger 1を 2013年5月 で公開しました。
- Googleは当初 2015年4月 でDagger 2を公開しました。
- 2016年9月15日 で、この質問が行われる10日前に、Dagger 1が非推奨としてマークされました。
その意味で、Guiceの継続的なキュレーションは、Daggerのどのバージョンよりも完全に先行する、長期にわたって広く消費されているソフトウェアパッケージのメンテナンスほど「車輪の再発明」ではありません。 DaggerはGuiceの精神的な後継者であると考えるかもしれませんが、Guiceの機能の最適化されたサブセットのみを提供するものです。
上記の違いをリストして修正するには：
- Springは、多くの統合、XML構成言語、およびランタイム/反射バインディングを備えた比較的重いフレームワークです。すでにSpringを使用しているアプリケーションは、Springの依存性注入フレームワークを追加作業なしで使用できます。
- Guiceは、統合が少ない比較的軽量なフレームワークであり、Javaインスタンス構成、およびランタイム/反射バインディング。Javaバインディングを使用すると、コンパイル-時間タイプのチェックとIDEオートコンプリート統合。
- Daggerは非常に軽量なフレームワークであり、統合はほとんどありません。Javaインターフェイス/注釈の構成、およびコンパイル時のコード生成バインディング。およびモバイル環境（AndroidのVMは、サーバーJREとは反射を特に遅くする方法が異なるため、ここではDaggerが特に役立ちます。）
- 上記の3つのフレームワークはすべてJSR-330をサポートしているため、適切に作成されたライブラリまたはアプリケーションは、使用されるDIコンテナーにほとんど依存しません。
さらに、使用するフレームワーク間でメンテナンス/非推奨のパターンとポリシーに注意してください。チームの知識と経験、リフレクションまたはランタイム構成の必要性、および統合とランタイムパフォーマンスの必要性に基づいて、上記のいずれかが目立つでしょう。そうは言っても、他にもフレームワークがありますので、上記の新しいオプションとフォークにも目を光らせてください。