XDocletはモノによってはマズいんじゃないの？
Java2 5.0が登場して，JavaプログラミングがMicrosoft Visual Studioにどんどん近づいてきている。その中でも特徴的なのが，アノテーションだろう。そしてJava2 5.0が登場する前から，ソースコードに注釈を入れて，それから定義ファイルなどを自動生成することができるXDocletが多くのプロジェクトで使われてきた。
確かに定義ファイルのメンテナンスは難しい。特にStrutsの設定ファイルであるstruts-config.xmlや，Spring Frameworkのapplication-context.xmlなどは，このファイルでアプリケーションの動作が決定される上に，記述量も半端じゃない量になるため，非常に気を使う。特にチーム開発であれば，１つのファイルを複数人で扱わなければならなくなるため，更に難易度はアップする。
そこでXDocletが活躍してきた。設定ファイルの各要素が，関連するソースコードに分散され，しかも実装＆設定が１ファイル中に存在するようになるので，いたって自然な記述になる。XDocletでstruts-config.xmlを出力する場合は，１アクションを複数パスで使いまわせないという制限があるが，その制限を受け入れて設計を行えば，俗に言うXML地獄からは解放される。
では，何でもかんでもXDoclet使って，ソースコード中に注釈を書いていけばいいのか？
例えば，最近はPOJO(Plain Old Java Object)という言葉が流行っている。アプリケーションを構成するコードが特定のクラスライブラリやフレームワークに依存してはならない，という考えだ。シンプルであればあるほど，使いまわしが効くようになるし，試験もし易くなる。
このPOJO，ソースコードレベルから特定のクラスライブラリやフレームワークに依存すべきではないと考えている。よくエンティティを表すモデルクラスのソースコードに注釈を記述して，Hibernateのマッピングファイルを自動生成する例を見かける。でも良く考えて欲しい。本来POJOなはずのモデルのソースコードが，Hibernateに依存してしまっている。もちろんコンパイルしたあとのクラスファイルはPOJOである。でも，使いまわすときはソースコードごと使いまわすのが現実では多いはずだし，結局Hibernate専用ソースコードになってしまった以上，そこから生成されるクラスはPOJOじゃない気がしてしまうのだ。
プログラムからモジュール間の依存関係や環境に影響される記述を排除するための設定ファイルだったはず。だったら，ソースコードレベルでもそういった依存情報は排除しておくべきじゃないのか？もしXML地獄が怖いのなら，それを軽減するためのやり方は他にいくらでもあるはずだ。
・・・とはいえ，やっぱり開発は楽に越したことはない。きっとPOJOだろうが何だろうがXDoclet使っちゃうんだろうなぁ，と自己嫌悪してみた今日この頃です。
