EclipseLink versus Hibernate

In my previous post I have started describing technology stack we use for typical business system with web interface. As I promised, now I am going into more details and advocating each of our choices. This post is devoted to EclipseLink and why we think it is better than its closest competitor – Hiberante.

For those who want to read why Hibernate is not a choice, I wrote a separate article in my personal blog.

Here I want to focus on what makes EclipseLink better than Hibername.

At first, both of them are java ORMs. Both now support JPA specification. Both are production ready. As Hibernate is older, it is even more popular currently.

I would like to define two criteria to compare these ORMs from the business point of view. Then I will go through some technical details to show why EclipseLink is simply better.

The business points are:

  • Predictability
  • Fragility


Let start with more simple thing – fragility. Just some statistical information. If you open issue trackers of both these products and search for all open CRITICAL and BLOCKER bugs you will see following picture (as for July 26, 2011) :


Name Number of bugs Number of blockers The oldest blocker
Hibernate 156 49 29/Sep/2006
EclipseLink 15 3 04/Jun/2010

Well, I think it explains itself. However I can only add we have made this short comparison not because we were curious, but because we really had too many problems with Hibernate stability. And now we have approximately 10 times less.


By predictability I mean an ability for developer to predict how the code he/she just have wrote will behave. Good library should have high level of predictability. However it is not the case with Hibernate.  Let me repeat my own post from the blog I already noticed:

Just a sample:

User user = loadUser(id);

It is a good old explicit statement which obviously loads user. How many SQL statements this call should execute? Normal answer is “one statement”. Something like

select * from users where id=?

But the true is in Hibernate it can be any number. Thousands or millions. And the most cool feature is this number may be easily (and often unintentionally)  changed in several different places of the code!

It is because of autoloading. When you designed User refers to a collection of Roles you most probably never thought that one of your colleagues will later add ref from Role to let say Permission. And another one (couple of weeks later) from Permission to something else.

As a result, your fast and pretty loadUser now executes 100 times slowly. And even when you accidentally find it you will have to analyze the whole model to understand what happened and then start with huge refactoring to make your code fast again without breaking codes of you colleagues (that relies on Permission collection now!)

Now let me explain why it does not happen to you with EclipseLink. Two facts:

1) This happen only to “eager” links. And does not happen to “lazy” links.

2) With EclipseLink you have no any reason to use eager links at all, while with Hibernate you have the reason for it

Lazy links and Lazy Initialization Exception

The reason is lazy links only works inside transactions in hibernate. It means if you load an object from database and close database connection such links will no longer work. If you try them, they will result in lazy initialization exception. So, standard strategy in hibernate is either to make a lot of links eager or to add a big set of methods like:

  • loadUser()
  • loadUserWithRoles()
  • loadUserWithRolesAndPermissions()
  • etc

With EclipseLink it is not the case. Lazy links will work even if you accidentally closed database connection. In such a case, EclipseLink will simply take a read-only connection from connection pool, execute loading and then put the connection back to pool. It will do it hiddenly, without bothering developer.

So, if developers simply make all the links lazy, it will work with EclipseLink and will solve the problem described above.


Even though EclipseLink does not solve all the problems, good ORM should solve in our opinion, it is currently the best java based ORM. And it is definitelly better that Hibernate.

This entry was posted in Blog and tagged , , , . Bookmark the permalink.

7 Responses to EclipseLink versus Hibernate

  1. Hiep says:

    your Fragility factor is not fair. Hibernate is older, it has definitively much bug/blocker/very old blocker than EclipseLink. What if the “small” user community of EclipseLink has not find out all the the bug of EclipseLink in all user cases, and one days the Eclipse Link will be stack up as many bug/bloker as Hibernate today?
    I’m saying that the tables that show number of bugs is interesting for curious peoples but it has no means. it’s be better to point out that EclipseLink is simpler, JPA-only. Hibernate is heavy, multi-purpose so, EclipseLink should be more stable than Hibernate…

    • roman says:

      Well, Hibernate was started at 2001 and TOPLink (the original name of EclipseLink) – in the beginning of 1990th. Java version of TOPLink was released in 1998.
      So, Hibernate is not older.
      It is more widely used, yes.
      However being a reference implementation of JPA, EclipseLink is also used by enough number of people to find blockers (if it would have them)
      We use it for more than 2 years and did not yet find any. While with Hibernate it was not a trick to start finding them during the first month of usage.

  2. Andy says:

    Some useful metrics, but not exactly thought through.

    If you are using JPA and using “extended” persistence context then you can obviously lazy load after a transaction is committed … with any JPA implementation … if they follow the JPA spec that is! DataNucleus JPA certainly allows that (since it still has the EntityManager and hence access to the connection pool). If using a “transaction” persistence context then all objects are detached at commit of the transaction hence they are not connected in any way to the persistence process and hence no lazy loading is going to happen.

    If you want to look at numbers of bugs and blockers, DataNucleus is shown here
    It has far far fewer (even by adding all of the DataNucleus subprojects) than either of your other two options FWIW. That may be a sign of far more active developer action, or less usage … but it started in 2003 building on the codebase of a project started in 2001). One thing is for sure, it gives far more predictable behaviour on all clients systems than the implementation(s) they used before trying it. As ever, try for yourself rather than believing claims, and make your own mind up

    • roman says:

      Well, we have used Data Nucleus with Google App Engine. It worked just fine.
      So, probably it does the same for rdbms as well.
      But would you move from one technology which works well to another which, as you hear, does the same? Or have you any special reasoning for such a switch?

  3. Pingback: JPA: which implementations support lazy loading outside transactions? | PHP Developer Resource

  4. OpenJPA is getting more popular now.

  5. hrauf1 says:

    I found Hibernate to be incomplete to use in my projects, whereas Eclipslink (or old name Toplink) is a breeze to start with.

Comments are closed.