「Reflector」
Javaのよく知られる限界の一つに、一旦クラスローダーにロードされたクラスを、新しいクラスファイルで更新できないというものがあります。これを克服したのは有名なJBossです。HotDeployには当時、４年ぐらい前でしょうか、RMIにはまっていた時、本当に驚いた覚えがあります。もちろんこの限界は技術的な限界というよりも、セキュリティ上の懸念ですね。
さて、J2ME上のリソースが少ない環境で同様な機能を実現できれば、組み込み開発分野で主流のC/C++に対する大きなメリットの一つとなるでしょう。オブジェクト指向の方法論を活用した生産性の向上は、特に技術者ではない経営に携わるかたがたには、見えにくいものですが、このように再プログラミング・ディプロイが不要になるメリットは目に見えるメリットです。
実はdb4oはこのようなアーキテクチャに柔軟に対応することができます。Reflectorというフレームワークがあるからです。このReflectorというのは、プラットフォームニュートラルなdb4oの保存形式と、Javaや.NETといった特定のタイプシステムをつなぐものです。Reflectorには、デフォルトで３タイプ用意されています。
- JdkReflector・・・javaのリフレクションを使用
- GenericReflector・・・あらゆるオブジェクトを表現できるGenericObjectを使用
- SelfReflector・・・ビルド時にJavaのリフレクションを使用してその情報を保存し、実行時にはリフレクションを使用せずにその保存済み情報を使用（CLDCやリフレクションが制限される環境）
さて、j2me上で実行時に変更できるダイナミックなオブジェクトを実現するには、目的に合ったダイナミックなオブジェクト構造を定義することです。この実装がどのような形であれ、それは実際のクラスで置き換え可能なものになります。db4oは、そのクエリ方式など、通常のオブジェクトに対して最適化されているため、このような構造のままでは十分な性能を発揮できません。
そこで登場するのがReflectorフレームワークです。このレイヤで、ダイナミックなオブジェクトを仮想のクラスに置き換えて格納・取得できるようにできます。これは上記３つのReflectorではなく、カスタマイズされたものが必要ですが、こうしてアーキテクチャにぴったりフィットさせることができるんです。
Genericsなどタイプセーフな傾向と、変更時期をコンパイル以降へと遅らる傾向は、一見矛盾しているようにも見えます。設計する人の頭の中では同じものなんですけどね。
興味がある人は、com.db4o.reflectパッケージをのぞいてみてください。結構面白いですよ。
