1年ほど前にJavaのORM（O/R マッピング）を調べた。そのときから、一番人気はHibernateだった。が、私は大いに気に入らなかった。
気に入らない点はいくつもあったが、なんといっても、「POJO」というバズワードだ。このバズワードは、臭う。かつて「has-a」だの「is-a」だのをこねくりまわしていた連中の匂いがする。
POJO党はコンテナ問題を持ち出すのが好きだ。いわく、コンテナ内でしか動作しないコードは、単体テストに時間がかかるのでよくない。だが、コンテナに依存しないこととPOJOであることは、まったくの別問題だ。コンテナの起動は時間がかかるので、コンテナへの依存性は最小限にしたいのは事実だ。しかし、永続化クラスに親クラスがないのが利点とは思えない。
（Cayenneの永続化クラスはCayenneDataObjectを継承しているが、コンテナのようなものは必要としない。引数のないコンストラクタでnewすることもできる）
POJO党は継承（特に多重継承）を嫌い、リフレクションを好む。私にいわせれば、リフレクションはsynchronizedやvolatileと同じくらい危険だ。世界のどこかには必要だが、可能な限り遠ざけておくべきものだ。
（CayenneはJavaのコードをツールで自動生成することでリフレクションを避けている）
『Hibernate イン アクション』を読んで、私はさらに論拠を得た。
筆者は、ORMのR（RDB）の部分を優先すべきだという。それと同時に、永続化クラス間に継承関係をつけられることを強調する。矛盾だ。よほど特定のRDBMSが好きなプログラマでもないかぎり、RDBのテーブル設計に継承などという概念は持ち込まない。
Hibernateの面倒くささは、この矛盾に端を発している。まるで、O側とR側にそれぞれ別のプログラマがいて、どちらも自分の設計を譲らない、という状態を想定しているかのようだ。
こんな状態を想定すること自体が間違っている。O側が譲るべきだ。さもなければOODBMSを採用すべきだ。データ構造とロジックでは、データ構造が上だ。
Javaは、委員会が設計した言語としては、史上初めての成功を収めつつある。委員会の呪いは、どこへ行ってしまったのだろう？――おそらくは、EJBへ。EJBにかけられた呪いときたら、並の委員会20個からそれぞれ代表を送って「委員会についての委員会」を作ったかと思われるほどだ。
EJB 3.0の永続化はHibernate風になるらしい。おそらく、今から3年後には、Hibernate風の永続化への呪いが世に満ちるだろう。