-SeasarとKijimuna - まさたか日記

Kijimunaは見ると分かるのですが、実装的にSeasarとはプログラム的に無縁のソフトウェアです。要は、s2のライブラリおよびコードを一切つかってません。その理由は、デザインタイムはJavaリフレクションが使えないことと、ClassLoaderおよびClassが意味を成さないことです。これは、コーディング途中のソースのコンパイル結果が無いということで（正確ではないですが）理屈づけることができます。同じように、Diconコンポーネントツリーも書き終わってないXMLはSeasarではなんともできません。しかし、Kijimunaは開発ツールなのでナントカしないといけません。そのために、KijimunaではSeasarの挙動を独自にエミュレートしています。
でも、これでいいのでしょうか？だってね、ひがさんと私と、同じ動きをする仕組みを作るのはもったいないじゃないですか。まあ、ひがさんほどじゃないにしても、私もそこそこ書けるわけですよ。そしたら同じ機能を二重に作るのではなく、別のパートを書くほうが社会貢献性が高い。ですから、数年後にやるかもしれないSeasar3では先にデザインタイムも考えた作りにしましょう。そのときもEclipseがあるか分からないけど、およそIDEの本質はひとつです。デザインタイムと実行時ではRTTIやローダーが違うってことです。Delphiではこのへん、メモリおよびストレージをバーチャルにすることと、RTTIにうまい仕組みがあって、実行時・デバッグ時・デザイン時に横断的・透過的な機能を提供しています。
具体的にKijimunaでエミュレートしたのは、Seasarがjava.lang.Classとjava.lang.reflection.*を使っているためです。コンテナの機能として、リフレクションばりばりになるのは仕方ありません。型はユーザーアプリケーションで決定するまで分からないですから。しかし、今のEclipseのアーキテクチャで解決できない、java.lang.Classとjava.lang.reflection.*を一枚抽象化した層の下に押し込むことで、デザインタイムも同じロジックを利用できます。

今日、なぜにこれを書いたかのは、これからSeasar2のコードをやり直してどうこうするということではなく（ちょっと今からやりなおすのは、Kijimunaもしんどいため）、新しいものが今開発中だから。つまりはS2JSFのツリーパーサーです。S2JSFは今作ってるものなのですから、ひと手間加えて、java.lang.Classとjava.lang.reflection.*が必要なところを、抽象化してほしい。それができていれば、相当早期にプラグイン対応できる可能性があります。HTMLのパーサーでJava型密着な仕組みがあるかはわかりませんが、もしあったなら、プラグイン対応する際にデザイン時必要な挙動をそろえるために時間を割かなくてもよい方法があるので、確認してもらえるとうれしいです。コンポーネントツリーを組み立てるところも該当するかもしれません。
ちなみに、KijimunaではEclipseでリフレクションするために、org.seasar.kijimuna.core.rttiというパッケージを作りました。また、Seasar2では使っていないognl-3.0.0-pre-2.jarを使って、org.seasar.kijimuna.core.rtti.ognlでOGNL式をデザインタイムに利用しています。