アスペクトを定義する @AspectJ アノテーション スタイルと、ajc コンパイラを使用する必要がある AspectJ Java 拡張言語の両方を使用できます。
ajc の代わりに注釈スタイルを使用する理由は何ですか? 注釈スタイルを使用することで多くの機能が放棄されているように思えますが、ajc を使用する必要がないこと以外には (もしあれば) あまり得られません (ajc を使用しなければならないことの何が悪いのですか?)
誰かがこのトピックについて教えてくれませんか?
両方のスタイル ( .ajと@AspectJ ) には、他のスタイルではできない機能があります。
宣言型の AspectJ ではできないことで注釈ができることについては、この投稿を参照してください: What is the AspectJ declarative syntax for overwritting an argument
ほとんどの.ajファイル (上記以外) は、さらに多くのことを実行できます。最も注目すべきは、ITD (Inter-Type-Definitions 別名クラスへのメソッドとプロパティの追加) を実行できることです。
@AspectJ を使用する最大の理由は、Spring プロキシ AOP サポートを使用する場合、コンパイル時間ウィービング (CTW) やロード時間 (LTW) さえも必要としないことです。Spring は @AspectJ を模倣しますが、実行時にプロキシを作成します。
私は、Spring、Eclipse (および私自身) が真の AspectJ の使用を促進しているように見えることに気付きました。これは、Eclipse プラグインが非常に優れているためだと思います。また、真の AspectJ と @Configurable アノテーションを使用すると、インスタンス化された Bean で Spring ワイヤリングを取得できます。これが Spring Roo の仕組みです。
Eclipse AspectJ IDE プラグインを使用すると、両方のスタイル (@ と aj) へのポイントカット参照を確認でき、「魔法」が起こっていることを非常に明確に把握できます。
ビルド プロセスにステップを追加することは、最も簡単で良い方法ではありません。特に大規模なプロジェクトがある場合。*.aj 構文をサポートしていない可能性のあるすべての Java ツールと IDE サポートから離れます。