TopLinkに対する感想

Seasar Conを前に、自分なりのTopLinkに対する感想を書くと・・・やはり完成度はHibernateの方が高いと思います。自分は既に実務でHibernate EntityManagerを使っているのですが、現時点でかなり安定していますし、独自機能のListener機能はJPA標準のListenerよりもかなり強力です。・・・ただ、Hibernateで落とし穴になりやすいN:1のLAZYロード機能については、TopLinkの方が優れていると思います（TopLinkでこの機能を有効にするのがかなり大変でしたが・・・）。TopLinkで惜しいと思うのは、HibernateのようにEntityManager.getDelegate()を使って独自のAPIを公開していない点です。現時点でのJPAは、JPQLの機能が不完全で、且つSQLを使うときのマッピング手法が面倒という２つの大きな欠点があります。Hibernateの場合、この２つの欠点を補う為に、Session.createSQLQueryメソッドを利用することが出来ます。SQLQueryを使えば、SQLの結果をJavaBean（not Entity）にマッピングすることが出来るので、DbUtilsのような利用方法も取ることができます。TopLinkの場合ネイティヴのAPIを公開していないので、JPAのnativeQueryメソッドを利用するしかありません。S2TopLinkではマッピングファイルの自動登録機能を提供するので、xmlファイルにResultSetのマッピング定義を書けば少しは面倒が軽減されるのですが・・・それでも自分は使い辛いと思います。現時点で適用を検討しようと思った場合、FROM句の副問い合わせやUNIONを使うようなSQLが必須のときは、TopLinkよりもHibernateの方が無難でしょうか。業務ではJPQLでサポートできるSQLが使えればよくて、更にＮ：１の関連定義について、Hibernateの動作では要件を満たせない場合、TopLinkは適用対象になってくるのかなと思います。個人的には、TopLinkはHibernateよりも綺麗にSQLをログ出力してくれるところが親切に感じてます。バインドするパラメータもしっかり出してくれますし。・・・ただ、ここにもオチがあって、TopLinkのログ出力はデフォルトではどうやらJavaSEのAPIを使うみたいです。リファレンスインプリになったが故の制限でしょうか（汗）・・・
今後、もし次のバージョンを出すようなときには、是非クラスエンハンス機能はInstrumentationを使うのをやめて、javassistやCGLIBのようにエンハンスクラスを別名で登録する手法に変更して欲しいですね。もうEntityのロード制限に悩まされるのはこりごりですので（苦笑）時代はHOT DEPLOYだというのに、TopLinkのEntityは動的変更どころか、システム初期化前にロードしないと使えないだなんて・・・不便すぎます。Hibernateの手法に切り替えた場合、persist機能が問題になりますが、mergeメソッドのように戻り値でエンハンスしたEntityを戻してやればOKだと思うし・・・
そしてSQLで出来る機能は全てJPQLでも実現して欲しい（少なくともFROM句の副問い合わせ・UNION対応は必須だと思います）。あと、SQLの結果を自動的にJavaBeanにマッピングして欲しい（現時点では、DbUtilsよりも退化してしまっています）。これらが揃えば、O/Rマッピングツールとしてかなり便利に使えるようになるのではないかと思います。
あと、これはTopLinkに限った話ではなくて将来のJPAに対する要望ですが、JPQLでQueryを実行するとき、Entityの子クラス（@Entityはつけていない）のクラスオブジェクトを引数に渡すと、その子クラスでインスタンス化されてデータが返ってくるような機能が欲しいですね。JPAの場合、継承戦略によって子クラスの定義があらかじめ決められていますが、テーブルとのマッピングとは別に、自由にクラスを継承して、更にEntity機能はそのまま利用する・・・そんな機能があれば便利かなと思います。Genericsと組み合わせれば、Daoは変更無しで戻ってくるオブジェクトを自由に拡張できるようになりますし。
あと、もう一つ欲しいのがEntityに対するステートレスロジッククラスのDI機能です。これが出来れば、DI環境でも積極的にドメインモデルを適用できそうな気がするので。これは既存のO/Rマッピングツールでは多分無理で、DIコンテナと連携しないと実現不可だとは思いますが。