内部で生成しているhbm.xmlのDTD指定がHibernate2.0のままで、Hibernate3だとネットからDLして確認するので、ネットにつながってない環境では動かないのに気付いて、ちゃんと3.0に変更しました。
というか、そのくらい普通のhbm.xmlを内部で生成しています。
無定義Hibernate
データベースのカラムを追加してもJavaコードから操作しないのであればマッピングをいじる必要がないというデモをしたのですが、実際やってみるとなかなかいい感じと自分でも関心。
Mapを使う場合と比べていいのは、必要なところでアクセッサが定義できるということですね。
いまのところフィルタの設定なんかができないので、実際には使えないですけどね。そこまでする気もないし。
Javaのコーディングはxxxより楽ですよ、という議論をするときにとてもいい(￣ー￣)
とりあえずDigesterアノテーションのBackport175版を作ろうと思ったら引数アノテーションが拾えないので、Genericsの型を拾いたいっていう要望と一緒にメールを送ってみた。
で、一応、要望は要望として送ったとして。
でも、Backport175って、ソース見るとコードの分量としてまじめにパースしてるとは思えないので、対応難しそう。JJTreeの定義がついてるけど、これはアノテーションの解析だけで。
今のバージョンのコードをちょこちょこ触っただけでは対応できないように見える。
Javaのコードもまじめにパースしないと、強いツールにならないんじゃないかなぁ。
本気でやるなら、自分らでやったほうが早いかも。
そしたら、クラスファイルにアノテーション埋め込むんじゃなくて、実行時に拡張Javassistでアノテーション埋め込むという実装にもできる。意味があるかどうかは別として。
なんか、EJB3見てるとJava5移行は思いのほか早く進みそうなので、あまりJava1.4にアノテーション持ち込む意味はないかも。
EJB3が使えずJava5が使えず、っていうところをターゲットにするというのはあるんだろうけど、backport175の現状での実装やbackport175使わない場合の手間を考えるとスタティック変数アノテーションでいい気がする。
アノテーション構文使いたければ、アノテーション構文からスタティック変数アノテーションに変換するプリプロセッサ作るほうが実用的かも。そうすると、本物のアノテーション構文で対応できるし。本物の構文使うなら、自分でjj書かなくても、JavaCCに付いてるやつが使えそう。
アノテーションとJavaコードを分離して、Javaコードだけ1.4javacに食わせて、あとからアノテーションバイトコードを載せるというのもいける。
アイデアは出したから、誰か実装して(^^
というのをMLに流そうと思ったら、どこがいいんだろう？
