Skip to main content

What do you prefer for enterprise Java persistence?

EJB 3.0
18% (279 votes)
EJB 2.x
2% (23 votes)
8% (117 votes)
11% (171 votes)
20% (300 votes)
30% (457 votes)
1% (8 votes)
1% (8 votes)
Something else (please comment)
2% (37 votes)
I don't develop enterprise Java
7% (110 votes)
Total votes: 1510



This is something that deserves attention. The Specification capability to avoid Database vendor lock-in, not only in terms of database vendor but also in terms of types of databases (RDBM database , OODB database, XML database, etc). I can say with no doubt, that JDO is the only Persistence specification that meets these requirements.

Object database

I prefer an Object database. OR mappers are very complicated. You have to learn one extra technology, config files, etc. etc.etc. We need urgently an powerful open source object database.


A vote for db4object.

iBatis SQL Maps

Another vote for iBatis SQL Maps. It's a great framework eh? - Peace

JPA - Java Persistence API - EJB 3.0

I've found that many people are confused about the relationship between these specifications. I suspect your poll results may be affected, but in any case, here is a quick recap.

JPA is a, non-standard, acronym for Java Persistence API. The specification was developed by the same Expert Group as EJB 3.0 but it is a separate spec. In particular, EJB 3.0 can only be implemented in the context of Java EE 5, while the Java Persistence spec can be implemented in many contexts, including plain Java SE. Unfortunately, when some people say "EJB 3.0", they really mean "Java Persistence".

There are several implementations of JavaPersistence, including TopLink Essentials (in GlassFish), Hibernate, Kodo and OpenJPA. Some of these implementations may also have other APIs, be for historical reasons or as extensions.

Hope this helps, - eduard/o

JPA - Java Persistence API - EJB 3.0

Ah, one more. There are two implementations that are often called "TopLink". TopLink Essentials is what is in GlassFish and it implements JavaPersistence. TopLink Essentials was started with a large contribution by Oracle that was based on their shipping TopLink product, which does not support JavaPersistence (to my knowledge). - eduard/o


After many tests and comparisons on EJB 2.0 Hibernate and JDO we found JDO as the best choiche for managing persistence in a mean web application. It's faster and less resource intensive than Hibernate or EJB 2.0. I'ts easy to configure for deployment and it's easy to integrate in Netbeans.

JDO of course

JDO2 is the most mature persistence specification. I really can't trust on anything else.

Better poll would have been ...

a specification-based poll, and then when you vote for a particular specification which implementation (if any) so would have had options like JPA (in general) JPA (Hibernate) JPA (Kodo) JPA (TopLink) JDO2 (in general) JDO2 (JPOX) JDO2 (Kodo) IBatis OJB Castor JDBC EntityBeans (EJB2) others

OJB - ObjectRelationalBridge

We have a production WebSphere Struts application running on z/OS. This is a SOX-compliant EPA tracking system that handles multi-million dollar transactions on a daily basis. For the past three years, OJB has been doing all of our DB2 persistence quite well. The Turbine-managed schema and object model is moderately complex (3-5 NF). We host our development/test environments on Windows and Linux using the same code in JBoss to connect to replicas in hSQLdb, MySQL, and PostgreSQL. While I am interested in JDO, Hibernate, etc... it is very hard to justify replacing OJB because it works so reliably.

Spring-Hibernate/Spring-JDBC template

Only reason for prefering Spring-Hibernate -Spring (Hibernate template) does a good job of mapping the lousy Hibernate Exception into more developer-friendly heirarchy of more meaningful exception types. Ditto for JDBC template ( used for simple Non-ORM DB access). Takes away the pain of SQLException and vendor-specific error codes. I am surprised that more than 20% still use JDBC. I'm just hoping they use it for Reporting Tools, for summarizing data (group by, sum(), avg() etc.) or such areas left uncovered by the ORM tools (AFAIK). JDBC is just too heavy and tedious for simple DB access needs. Time someone gave a serious thought to introducing LINQ in Java?

Choice of three

I'm a little torn with JPA up there (which is what I voted for). JPA is an API that is implemented by Hibernate and EJB3, so while I'd probably be using Hibernate if I had my choice I'd take care to write to the JPA spec (which would require Hibernate 3.2 of course).

I prefer Ibatis over Hibernate

I prefer Ibatis. It doesn't have issues like Hibernate opensessioninview and lazy-loading issues. SQL is simple, universal. Ibatis gives me good control. Hibernate has HQL, Criteria API, hardcoding sql-like syntax in ugly java code. Ibatis is far more practical to me.