java.net に掲載されている「Java Persistence Frameworkの選択:選択肢、適した状況、そして利点と欠点(source)」というSharad Acharya氏の記事では、CMP Entity EJBs、JPA、Hibernate、TopLinkの4つの一般的な永続化フレームワークを比較している。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は即座にクローズされるでしょう。単なる個人的な意見ですが。
原文はこちらです:http://www.infoq.com/news/2008/01/16