2

私は、ソーシャル ネットワーク データの消費を支援するフレームワークであるAgoravaのテクニカル リーダーです。

現在、Agorava は Java EE スタックでの使用を容易にするために CDI 上に構築されていますが、Android で動作するより軽量なソリューションを実現するために、Dagger を使用した実装を提供したいと考えています。

私の質問は、CDI と Dagger の実装の間で、共通の JSR 330 準拠のコードを共有できますか? つまり、Dagger を使用して、JSR 330 アノテーションを付けた jar にコードをコンパイルし、ソース コードを拡張したり、Dagger 固有の Jar でこのコードを使用したりすることは可能@Providesです@Modulesか?

答えが「いいえ」の場合、一般的な JSR 330 jar を Dagger コンパイラでコンパイルし、それを CDI 実装で使用することに問題はありますか? より正確には@Inject、修飾子やその他の JSR 330 仕様は実行時に引き続き利用可能であり、これらのアノテーション コードを持つクラスは Dagger コンパイラによって変更されないままになりますか? 最後に、Dagger で生成されたコード (クラス名、注釈) に、CDI がそれを検出して無視できるようにする一種のトラッカーがありますか?

4

1 に答える 1

5

コードが Dagger と互換性のない動作を実装していない限り、Dagger と他の JSR-330 実装の間でクライアント コードを共有できます。たとえば、Dagger 1.0 はメソッド インジェクションをサポートしていません。Dagger 2.0 はインジェクターの代わりにコンポーネント インターフェイスを使用するため、コードはそれを気にする必要はありません。

@Inject およびその他の JSR-330 API 要素は、実行時に引き続き表示されます。Dagger は実行時にそれらにアクセスせず、コンパイル時に生成されたコードを作成して、実行時にこれらの注釈を解釈します。ただし、これらのクラスは、すべての JSR-330 アプリに対して有効な JSR-330 準拠の注入可能なクラスです。

問題になる可能性があるのは、Dagger がこれらの余分なクラスを生成するため、jar を後処理するか、ビルド システムを再構成して、生成されたコードを取り除き、補助的な jar に移動する必要があることです。しかし、これはビルド システムの構成の問題であり、dagger を使用するアプリケーションで実行時に生成されたコードを使用できる限り、dagger はそれに依存しません。

ビルド時のオプションの 1 つは、コンパイラを -proc:none で実行し、2 番目の構成で -proc:only を使用して実行し、後者の出力を別の出力フォルダーにパイプして、それを jar にすることです。これは、maven-compiler-plugin をさまざまに実行することで、maven で実行できます。

Dagger で生成されたクラスにはすべて @Generated が必要ですが (近日公開予定)、すべてが dagger.internal.ModuleAdapter、dagger.internal.Binding、または dagger.internal.StaticInjection から派生しています。これらのサブクラスはすべて、非短剣フレームワークによって安全に無視できます。実際、彼らは保護されている可能性があります。

于 2013-09-05T16:38:24.527 に答える