SQL Zone is brought to you in partnership with:

Pos Graduation : MIT Software Engineering – Java (Infnet College) Developer Experience: 10+ years on systems developments 7+ years as Delphi developer 3+ years as Java developer 8+ months as Java teacher Agile, Scrum, TDD SQLServer, Oracle, Postgres, MySQL Java Certifications: SCJP (1.6) SCWCD (1.5) OCBCD In Progress Hebert is a DZone MVB and is not an employee of DZone and has posted 7 posts at DZone. You can read more from them at their website. View Full User Profile

JPA Hibernate Alternatives: When JPA & Hibernate Aren't Right for Your Project

  • submit to reddit

Hello, how are you?

Today we will talk about situations in which the use of the JPA/Hibernate is not recommended. Which alternatives do we have outside the JPA world?

What we will talk about:

  • JPA/Hibernate problems

  • Solutions to some of the JPA/Hibernate problems

  • Criteria for choosing the frameworks described here

  • Spring JDBC Template

  • MyBatis

  • Sormula

  • sql2o

  • Take a look at: jOOQ and Avaje

  • Is a raw JDBC approach worth it?

  • How can I choose the right framework?

  • Final thoughts

I have created 4 CRUDs in my github using the frameworks mentioned in this post, you will find the URL at the beginning of each page.

I am not a radical that thinks that JPA is worthless, but I do believe that we need to choose the right framework for the each situation. If you do not know I wrote a JPA book (in Portuguese only) and I do not think that JPA is the silver bullet that will solve all the problems.

I hope you like the post. [=

JPA/Hibernate problems

There are times that JPA can do more harm than good. Below you will see the JPA/Hibernate problems and in the next page you will see some solutions to these problems:

  • Composite Key: This, in my opinion, is the biggest headache of the JPA developers. When we map a composite key we are adding a huge complexity to the project when we need to persist or find a object in the database. When you use composite key several problems will might happen, and some of these problems could be implementation bugs.

  • Legacy Database: A project that has a lot of business rules in the database can be a problem when wee need to invoke StoredProcedures or Functions.

  • Artifact size: The artifact size will increase a lot if you are using the Hibernate implementation. The Hibernate uses a lot of dependencies that will increase the size of the generated jar/war/ear. The artifact size can be a problem if the developer needs to do a deploy in several remote servers with a low Internet band (or a slow upload). Imagine a project that in each new release it is necessary to update 10 customers servers across the country. Problems with slow upload, corrupted file and loss of Internet can happen making the dev/ops team to lose more time.

  • Generated SQL: One of the JPA advantages is the database portability, but to use this portability advantage you need to use the JPQL/HQL language. This advantage can became a disadvantage when the generated query has a poor performance and it does not use the table index that was created to optimize the queries.

  • Complex Query: That are projects that has several queries with a high level of complexity using database resources like: SUM, MAX, MIN, COUNT, HAVING, etc. If you combine those resources the JPA performance might drop and not use the table indexes, or you will not be able to use a specific database resource that could solve this problem.

  • Framework complexity: To create a CRUD with JPA is very simples, but problems will appear when we start to use entities relationships, inheritance, cache, PersistenceUnit manipulation, PersistenceContext with several entities, etc. A development team without a developer with a good JPA experience will lose a lot of time with JPA ‘rules‘.

  • Slow processing and a lot of RAM memory occupied: There are moments that JPA will lose performance at report processing, inserting a lot of entities or problems with a transaction that is opened for a long time.

After reading all the problems above you might be thinking: “Is JPA good in doing anything?”. JPA has a lot of advantages that will not be detailed here because this is not the post theme, JPA is a tool that is indicated for a lot of situations. Some of the JPA advantages are: database portability, save a lot of the development time, make easier to create queries, cache optimization, a huge community support, etc.

In the next page we will see some solutions for the problems detailed above, the solutions could help you to avoid a huge persistence framework refactoring. We will see some tips to fix or to workaround the problems described here.

Published at DZone with permission of Hebert Coelho De Oliveira, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


John J. Franey replied on Mon, 2014/08/25 - 11:50am

Two points:

1) Running a query 'without a transaction' will lead to lazy load problems.   If any of your reader's is a green newbie, and takes your code, and has a lazy load relationship from Student, then you just gave him a bug.

2) In each comparison to JPA, you don't mention how the alternative addresses the shortcomings of JPA.   To what extent to the alternatives alleviate the composite key problem, the 'artifact size' problem or the compext sql generation?

Chris Clark replied on Wed, 2014/08/27 - 6:03am

I've been using JPA for years and whilst I totally agree it's not the solution to all I don't think it's the really that hard. Like most technologies it's easy to implement it badly. Composite keys really aren't that complex, ie Embeded keys, hard really??? Kind of agree for stored procedures but you wouldn't lose the database implementation but the JPA implementation (http://objectopia.com/2009/06/26/calling-stored-procedures-in-jpa/) and really lets be honest how many times have you moved to a different implementation of JPA? For each of points of concern you mention the same could be said for all of the alternatives you offer. If you do use hibernate then how cool is the hibernate second level cache? You can also tune your queries to hit indexes and they don't have to be native at all.   

Neil Stockton replied on Thu, 2014/08/28 - 7:50am in response to: Chris Clark

I've moved JPA implementations, but this wasn't down to one providing a vendor extension and another not, but more down to one having significant bugs (even though it had been mandated by management), and the one we moved to not having these bugs. But again, moving JPA implementations is easy really ... different jars in the CLASSPATH, and minor updates to persistence.xml and you're away.

There are situations where you don't need JPA, but judge them on a case-by-case basis

Roger replied on Fri, 2014/08/29 - 4:19am

Good timing I'm actually just started working on a alternative to ibatis that just plug on top of jdbc and is optimized for performance :


It's just focusing on the object mapping from the result set, and can easily be used as a RowMapper for spring jdbc.

Yannick Majoros replied on Mon, 2014/09/01 - 10:59pm in response to: Chris Clark

@Chris Clark +100, the points you're outlining makes me wondering if they've been checked thoroughly in this article. 

Composite keys (multiple ways of doing it, if you really can't normalize your db), performance (sure it isn't just an understanding problem?), stored procedure (see jpa 2.1, for what you couldn't do with 1/2)...

One more thing that's even more important to me: as hip as all those "frameworks" sound, they aren't standards. That means no JSR, single implementation, no open public thinking process before jumping to code. Will most of those still be around in a couple of years? I know this could sound boring, but that's the part I like most in Java EE and that is unique in it.

JPA is difficult. And worth learning. Will it solve all your problems? Sure it won't. But face it, it does solve most enterprise persistence needs, and is a standard. Better have some serious needs that really don't match JPA if you need something else and don't want to regret it.

Hebert Coelho D... replied on Tue, 2014/09/30 - 1:56pm in response to: John J. Franey

 Hello John,

  1. It will lead to lazy load if you do not do the fetch in the query. In the blog there are several posts talking about this problem and showing how to solve it. [=
  2. I do talk about it in solutions page. [=

Thanks for the comments

Hebert Coelho D... replied on Tue, 2014/09/30 - 2:05pm in response to: Chris Clark

 Hello Chris,

I do agree with that change the JPA implementation do not happens all the time, but I already had to do it because of a implementation bug. I do know other developers that did the same. =/

You have no idea of the amount of emails or comments in the blog about composite keys / embedded keys. 

About the StoredProcedures the solution really is a NativeQuery or the new JPA implementation.

About the second level it is a wonderful tools, but I have seen a lot of people that do knot know how to use it. A developer that does know how to use, usually, are expensive and companies do not has the required money to keep them. =/ That is a sad reality in Brazil. =/

Thanks for the comments. =D

Hebert Coelho D... replied on Tue, 2014/09/30 - 2:06pm in response to: Neil Stockton

 Hello Neil.

I do agree with your. I had some bug problems too.

Thanks for the comment! (:

Hebert Coelho D... replied on Tue, 2014/09/30 - 2:08pm in response to: Roger

 Hello Roger,

Thanks for the comment. [=

Hebert Coelho D... replied on Tue, 2014/09/30 - 2:24pm in response to: Yannick Majoros

 Hello Yannick,

I have looked all the questions in my blog and Composite is a problem that people asks a lot, and a know hundreds of developers (you can be sure that are hundreds) that are not able to normalize the DB. What is the point in keeping Hibernate with this kind of DB? It will cause you more harm than good. Performance is a problem with you have a lot of batch operations and several transactions per seconds, some times a good a approach is not using JPA. You could do several things to solve this problem, but does every company has the required knowledge to do it? About stored procedure I talk about JPA 2.1 or native query.

If non JSR frameworks is a problem than Spring could be ignored? Or Guava? Or C3P0? I do believe that some framework vanish and we stay without support, but I think that is not a reason that we could not see "out of the JSR" box.

Yes, I do agree that JPA solves most of our problems. But I do not think that is better have it in every situation, there is a world of good and stable solutions outside.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.