JPA Frameworks Compared
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:
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.
Simple, flexible framework that is completely free and easily integrated with other frameworks, but may have support issues related to being open source.
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.
Toplink.. Oracle centric? Why that?
Toplink is authored today by Oracle that is true, but as you know it is becoming fully open source as part of the EclipseLink project.
And from the beginning Toplink has been a portable solution that you can use in any Java environment. (JavaEE or JavaSE) without dependencies on Oracle (database or middleware).
It is also true that Toplink has some special features that are enabled and deployed when it is running in the OracleAS environment, but that does not mean it is Oracle centric.
And finally, Toplink Essentials is the Reference Implementation of JPA, and part of the Glassfish project... that is for sure not Oracle centric.
Editorial standards sink low
And regarding the "free" support for the OSS project, our commercial team consistently utilizes JBoss forums for free spuport, and has had consistently excellent experience. But it does help that we don't have an ax to grind like a lot of people seem to, and we also don't mind being told when we're wrong. Grow a thicker skin! Hell! Being told what we're doing wrong is what we're there for, not for some coddling reach-around.
We do often notice that the volume on Hibernate forums is high, due to its widespread use. Sounds like a feature rather than a bug to me ;-)
And speaking of widespread use, pick up any of the gazillions of manuals on JPA or Hibernate and you're in business. Hibernate maintainers plainly state that they get you started quickly on the common stuff but they also intend to support the complex contortions required when you're dealing with a messy legacy RDMBS.
Here's the thing, I'd be quite happy to use Toplink in a heartbeat now that it is truly "open". But I am rather glad in general that my team is dealing with the more widely used Hibernate implementation. It's not 6 of one, 1/2 a dozen of the other, in my opinion, because Hibernate is definitely "opinionated software". Some people like that. Some people don't.
I can easily make the case for using a non-automatic ORM-like system, such as iBATIS in some cases, although that's a matter of personal taste and stupid religious debates for many people. But at least iBATIS is a a whole lot more interesting a comparison than Toplink v Hibernate.
The other two compared above don't count: its really pretty retarded to see JPA, a specification not a product, and EJB CMP, which is almost single-handedly responsible for the disdain that most of the world holds for EJB, compared side-by-side as if it was chocolate, vanilla, or strawberry.
How Can We Use Our Creative Power and Technological Opportunity to Address the Challenges of the 21st Century?
Gyorgyi Galik Feb 26, 2015