java.net is hosting an article written by Sharad Acharya titled "Java Persistence Framework: Which, When, and What?" that compares four popular persistence frameworks: CMP Entity EJBs, JPA, Hibernate, and TopLink. Acharya discusses each technology and summarizes his findings in a matrix that boils down to:
JPA
Simple framework for both J2SE and J2EE applications that incorporates many useful features from other frameworks but requires Java 5 or higher.
CMP Entity EJBs
J2EE container provided framework with useful security and transaction management, decent scalability, and distributed component capabilities, but can be resource-intensive and complex to learn and use.
Hibernate
Simple, flexible framework that is completely free and easily integrated with other frameworks, but may have support issues related to being open source.
TopLink
Oracle-centric framework that is very mature but also closely tied to a single vendor.
The article generated a fair amount of comment activity, particularly around the relationship between JPA and Entity Beans in EJB 3.0 and the potential liabilities of Hibernate being open source.
One commenter wrote regarding Entity Beans and JPA:Another complained about the characterization of open source as a liability:The article discusses Bean-Managed Persistence (BMP) with JDBC versus Container-Managed Persistence, but EJB 3.0 introduced an entirely new model for entity bean persistence. I must assume that the author is discussing EJB 2.x at this point.
Discussion of the "remote interface model" also implies that the author is still talking about EJB 2.x and strengthens the assumption that most of the background information and the drawbacks listed in this article for Enterprise JavaBeans are actually for EJB 1.x and EJB 2.x rather than for EJB 3.0.
It is a little confusing because the author references EJB 3.0's use of annotations to remove many of the coding difficulties commonly associated with previous incarnations of EJB, but then in the next sentence says, "The EJB architecture is non-trivial to learn and use" and lists some of the things commonly associated with previous EJB versions.
The author also talks about EJBs not being usable in other frameworks, but EJB 3.0 uses "normal" Java classes which can be used in other frameworks as long as those frameworks ignore the JPA annotations on the normal Java class.
JPA was created as part of the EJB 3 specification and is an inherent part of EJB 3. The specification creators made sure that conforming implementations of the JPA would support SE environments. The author mentions that JPA can work in both EJB and SE environments, but then goes on to state that Java EE 5 is required to use JPA. This is not true because SE does not have a dependency on EE in order to make JPA work.
One "liability" of JPA listed in this article is the need for a vendor to provide a JPA limitation. The fact is that a "vendor" is required for all these implementations, including Hibernate (which is a "vendor" of a JPA implementation as well). Someone has to write the library or framework and the only question is if it is a standards-compliant library or framework or not. While some of the other covered frameworks "may" be standards-based (built on standards), the Java object-relational mapping persistence framework that is itself a standard is the Java Persistence API.
There is a one-way dependency between EJB 3.0 and JPA. Any EJB 3.0 implementation should be expected to be heavily JPA-based, but the presence of JPA does not necessarily imply EJB because Java SE can use JPA.
While I think you have some points I don't agree with the plain statement that "open-source is liability". Actually, this a kind of misleading argument that may in fact add liability to your project. I worked in a project that decided to use Kodo instead of Hibernate just because LGPL was not friedly enough (liability, etc.). When I look at the code now I see how bad this decision was... Hibernate was far superior at that time and still is IMO. Maintenance is harder and tricky. Your mileage may vary though...Although several people chimed in to support the author's assertion:
Open-source projects in general *are* a liability but Hibernate specifically has a serious support problem. Unless you pay the organization money you will find their support is terrible. Bug reports and feature requests will get closed with rude remarks. Posts on discussion forums get ignored. General (free) support is very hard to come by.
Anyone considering using Hibernate should realize that 90% of the time it works like a charm, but you waste *days* fixing problems with the other 10%. This is how they make their money, as do many other open-source projects, by making the product harder to use and charging for support.
The biggest ease-of-use concern with Hibernate are its exception messages. Sometimes you get misleading error messages that point you in the wrong direction. Other times you get messages that are so vague you have no idea what has gone wrong. If you file a RFE asking them to improve error reporting you will get a rude remark and the RFE will be closed promptly. Just my 2 cents.