続：XDocletはモノによってはマズいんじゃないの？
この前書いた以下の記事で， NetPenguinクンからコメントをもらった。
XDocletはモノによってはマズいんじゃないの？ よくエンティティを表すモデルクラスのソースコードに注釈を記述して，Hibernateのマッピングファイルを自動生成する例を見かける。でも良く考えて欲しい。本来POJOなはずのモデルのソースコードが，Hibernateに依存してしまっている。もちろんコンパイルしたあとのクラスファイルはPOJOである。でも，使いまわすときはソースコードごと使いまわすのが現実では多いはずだし，結局Hibernate専用ソースコードになってしまった以上，そこから生成されるクラスはPOJOじゃない気がしてしまうのだ。
上記の考えに変化はないけど，NetPenguinクンからの「どう解釈するかはその時々で任意に決めれる」というアノテーションに対する考え，かなりピーンと来た。
Java2 5.0のアノテーションで必ずといっていいほど登場する例で，「@remote」という注釈をメソッドに付けるパターンを良く目にする。この@remote，EJBであれば，RemoteインタフェースやDDが生成されるだろうし，CORBAであればIDLが生成されるだろう。また，今後登場するであろう未知のオブジェクト間リモートメッセージ送受信にも，@remoteという注釈名であれば対応できる。
つまり，注釈として記述されるものには，抽象的な記述が求められる。抽象的と言うか，本質的な目的というか，，，そういうものだ。「 XDocletはモノによってはマズいんじゃないの？」で記載した，XDoclet使ってHibernateのマッピングファイルの自動生成を行う場合の注釈に対して，僕は違和感を感じていたのだ。
注釈を入れる以上，そのクラスの利用目的をある程度限定しようとしているはずである。つまり，完全なPOJOにするつもりはないはずなのだ。ただし，ある範囲でソースコードはやはり使いまわしたい。例えば，RDBの表に格納された情報を保持したいクラスなんだけど，特定のO/Rマッピングツールには依存したくない，というときだ。この場合の注釈は，
- @hibernate.class table=”customer”
ではなく，
- @rdb.class table=”customer”
なら，納得なのである。ただし， NetPenguinクンも指摘しているように，最終的な目的は，注釈から何らかのツールやフレームワークに依存するファイルを生成したいわけで，それに十分な記述を上記のような抽象的な記述で満たせるのか？は大いに疑問が残る。ツールに依存する部分だけは別ファイルで・・・なんて考えてしまうと，きっと注釈使う意味がなくなっちゃうんだろうし。。。難しいです。
ちなみに，struts-config.xmlを生成するための注釈をActionクラスに記述することについては何の問題もないだろう。だって，Actionクラスの利用範囲はStrutsしかないのだから。
