-AOP Alliance

ひがさんがSeasar2AOP Allianceに対応させることを表明しています。からさわぎでも話題になりましたが、このAOPのところが各AOP対応コンテナで標準化しないと、せっかくPOJOでコンポーネントが書けるIoCコンテナも、Adviceはコンテナ密着となってしまうので「将来は」と予測するものだったのですが、もうありましたか。サイトを見るとAOP AllianceのAPI-JavaDocが見れます。もちろん「unstable」ですけど、結構詰められているように思います。コンテナだけでなく、AOPコンパイラやツール等汎用に用いるAPIのために、インターフェイス数個というSeasar2のシンプルなものから雰囲気変わりそうですが、AOP周りのSeasar2成果物が他プロジェクトと混用可能になるというのはステキだと思います。メンバーリスト見ると、Spring FrameworkのRod Jhonson氏とかに混じり、千葉博士の名前が。この方はJavassist作った人です。それだからか、バイトコードエンジニアリング機能/ライブラリのサービスインターフェイスも用意されています。有用かどうかは不明ですが、Seasar2ではCGLibが組み込まれているところ、Javassistに取替え可能になったりできそうですね。
注目なのは、Interceptorインターフェイスの派生で、MethodInterceptor、FieldInterceptor、ConstructorInterceptorがAPIに用意されています。実行時にAOPするコンテナでは、カプセル化よりFieldの直アクセスを可能とするのはネガティブかな思いますが、あれば結構使えるものなのかもしれません。Singleton基本のIoCコンテナのパターンでは、Constructorのほうはあまり意味がない。一度しか作りませんし、Seasar2ならType4の初期化メソッドでAfterのAdviceならIoCコンテナのほうに分類される機能で同様のことができます。結局は今のSeasar2のAroundAdviceにちょうど当たるMethodInterceptorだけでよいのかなと思ってますが、押して考えると、Constructorよりはコンテナから参照されたときのほうがAdviceで引っ掛ける意味がすこしはあるかもしれません。こちらはIoCのほうに分類される機能ですね。AOPというよりは普通にコンテナのリスナー機能になるかと思います。
さて、そのAOP AllianceのMethodInterceptorは以下です。

package org.aopalliance.intercept;
public interface MethodInterceptor extends Interceptor {
  public Object invoke(MethodInvocation invocation) throws Throwable;
}

invoke()メソッドの引数のMethodInvocationは、org.aopalliance.intercept.Joinpointインターフェイスを継承しています。MethodInterceptorが継承するInterceptorは、メソッド定義を持たないマーカーインターフェイスです。対比して、以下Seasar2のAroundAdviceです。

package org.seasar.framework.aop;
public interface AroundAdvice {
  public Object invoke(Joinpoint joinpoint) throws Throwable;
}

とてつもなく良く似ています。