JPAフレームワークの比較

java.net に掲載されている「Java Persistence Frameworkの選択：選択肢、適した状況、そして利点と欠点(source)」というSharad Acharya氏の記事では、CMP Entity EJBs、JPA、Hibernate、TopLinkの４つの一般的な永続化フレームワークを比較している。Acharya氏はそれぞれの技術について論じ、調査結果をマトリックスにまとめている。要約すると以下のようになる。

JPA
J2SEとJ2EEのどちらのアプリケーションでも使えるシンプルなフレームワークで、多くの便利な機能を盛り込んだものである。ただしJava 5 以上が必要。

CMP Entity EJBs
J2EEコンテナが提供するフレームワークで、実用的なセキュリティやトランザクション管理、優れた拡張性、そして分散コンポーネントの機能を持つ。しかし、リソース集中型になることがあり、また習得し活用するには手間がかかる。

Hibernate
シンプルで柔軟なフレームワークで完全にフリーになっており、簡単に他のフレームワークと統合することができる。ただし、オープンソースであることに関連したサポートの問題があるかもしれない。

TopLink
Oracleが中心となっているフレームワークで非常に成熟しているが、たったひとつのベンダに密接に結びついている。

この記事にはかなりの数のコメントが寄せられたが、特にJPAとEJB 3.0のEntity Beansとの関係と、オープンソースであるHibernateの潜在的にマイナスな点に関するものが多かった。

この記事ではJDBCを使ったBean-Managed Persistence（BMP：Bean管理による永続化）とContainer-Managed Persistence（CMP：コンテナ管理による永続化）を対比して論じていますが、EJB 3.0ではEntity Beanの永続化に全く新しいモデルを導入しています。この点で、著者はEJB 2.xについて論じていると想定しなければなりません。

「リモート・インタフェース・モデル」に関する話も、著者がまだEJB 2.xについて話しているということを示しており、基本的な情報やこの記事でリストアップされた欠点の大半がEJB 3.0よりはむしろEJB 1.xやEJB 2.xについてのものであるという仮定を補強しています。

以前のEJBに一般的に付き物であるコーディングの難しさの多くを取り除くものとして、EJB 3.0のアノテーションの利用を参照しているためにちょっと混乱させられますが、次の文では「EJBのアーキテクチャを習得し活用するのは簡単ではない」と述べていて、一般的に以前のバージョンのEJBに付き物の事柄をいくつかリストアップしています。

著者はEJBが他のフレームワークでの使用に適さないとも述べていますが、EJB 3.0は「標準の」Javaクラスを使っているので、他のフレームワークが標準のJavaクラスに書かれたJPAのアノテーションを無視しさえすれば使用することが出来ます。

JPA はEJB 3の仕様の一部として作成されたものでEJB 3の固有の部分です。仕様の作者達はJPAに準拠した実装がSEの環境をサポートすることを確認しました。著者はJPAがEJBでもSEの環境でも動作することに言及していますが、そのすぐ後でJPAを使用するためにはJava EE 5が必要であるとはっきり述べています。SEでJPAを動作させるためには、EEへの依存関係はなく、これは事実ではありません。

この記事で挙げられているJPAの不利な点の一つはJPAの制限に備えるためにベンダが必要なことです。事実、「ベンダ」はHibernate（これも JPAの実装の「ベンダ」の一つ）を含め、これらの実装の全てに必要です。誰かがライブラリやフレームワークを書く必要があり、唯一の論点は、標準に準拠したライブラリやフレームワークであるか否かということです。他のカバーされたフレームワークのいくつかは標準ベースの（標準に基づいた）もの「かもしれません」が、それ自身が標準であるJavaのO/Rマッピングの永続化フレームワークはJava Persistence APIです。

EJB 3.0とJPAには一方向の依存関係があります。どんなEJB 3.0の実装も、しっかりとJPAに基づいていることが当然期待されますが、JPAの存在は必ずしもEJBを必要とするわけではありません。Java SEはJPAを使用することができるからです。

私には同意できない点があるのですが、それは「オープンソースであることはマイナスなことだ」としていることです。実際、これは誤解を招く恐れのある主張であり、それどころか、あなたのプロジェクトの障害を増やすかもしれません。私は、LGPLは（義務などのため）使いづらいというだけで、 Hibernateの代わりにKodoを使うことにしたプロジェクトで働いていました。今コードを見ると、この決定がどれほどまずいことだったかがわかります。Hibernateはその時点ではるかに優れていましたし、私の意見では今でもそうです。保守は難しくて大変です。あなたのメリットは困難に代わるかもしれません...。

オープンソースのプロジェクトは概して不利な点があるものですが、特にHibernateには深刻なサポートの問題があります。お金を払った場合を除いて、サポートがひどいと感じるでしょう。バグレポートや機能のリクエストは失礼な意見とともにクローズされるでしょう。ディスカッション・フォーラムへの投稿は無視されます。一般の（無料の）サポートを受けるのは非常に難しいのです。

Hibernate を使うことを検討している人は誰でも、90%は見事に動作しますが、残りの10%にともなう問題を解決するために「何日も」無駄にすることに気づくはずです。これが彼らのお金の儲け方であり、他の多くのオープンソース・プロジェクトがしているように、使いにくい製品を作ってサポートに課金するのです。

Hibernate の使い勝手の良さに対する最大の懸念は例外発生時のメッセージです。間違った方向を示すような誤解を与えるメッセージが返されることがあります。またある時には、メッセージがあまりにも漠然としていて何がエラーとなったのかわからないことがあります。もし機能追加要求（RFE）を出してエラーレポートを改善するように依頼したら、失礼な意見が返されRFEは即座にクローズされるでしょう。単なる個人的な意見ですが。