JPA Hibernate Alternatives. What can I use if JPA or Hibernate is not good enough for my project?

Solutions to some of the JPA/Hibernate problems

We need to be careful if we are thinking about removing the JPA of our projects.

I am not of the developer type that thinks that we should remove a entire framework before trying to find a solution to the problems. Some times it is better to choose a less intrusive approach.

Composite Key

Unfortunately there is not a good solution to this problem. If possible, avoid the creation of tables with composite key if it is not required by the business rules. I have seen developers using composite keys when a simple key could be applied, the composite key complexity was added to the project unnecessarily.

Legacy Databases

The newest JPA version (2.1) has support to StoredProcedures and Functions, with this new resource will be easier to communicate with the database. If a JPA version upgrade is not possible I think that JPA is not the best solution to you.

You could use some of the vendor resources, e.g. Hibernate, but you will lose database and implementations portability.

Artifact Size

An easy solution to this problem would be to change the JPA implementation. Instead of using the Hibernate implementation you could use the Eclipsellink, OpenJPA or the Batoo. A problem might appear if the project is using Hibernate annotation/resources; the implementation change will require some code refactoring.

Generated SQL and Complexes Query

The solution to these problems would be a resource named NativeQuery. With this resource you could have a simplified query or optimized SQL, but you will sacrifice the database portability.

You could put your queries in a file, something like SEARCH_STUDENTS_ORACLE or SEARCH_STUDENTS_MYSQL, and in production environment the correct file would be accessed. The problem of this approach is that the same query must be written for every database. If we need to edit the SEARCH_STUDENTS query, it would be required to edit the oracle and mysql files.

If your project is has only one database vendor the NativeQuery resource will not be a problem.

The advantage of this hybrid approach (JPQL and NativeQuery in the same project) is the possibility of using the others JPA advantages.

Slow Processing and Huge Memory Size

This problem can be solved with optimized queries (with NativeQuery), query pagination and small transactions.

Avoid using EJB with PersistenceContext Extended, this kind of context will consume more memory and processing of the server.

There is also the possibility of getting an entity from database as a “read only” entity, e.g.: entity that will only be used in a report. To recover an entity in a “read only” state is not needed to open a transaction, take a look at the code below:

String query = "select uai from Student uai";
EntityManager entityManager = entityManagerFactory.createEntityManager();
TypedQuery<Student> typedQuery = entityManager.createQuery(query, Student.class);
List<Student> resultList = typedQuery.getResultList();

Notice that in the code above there is no opened transaction, all the returned entities will be detached (non monitored by the JPA). If you are using EJB mark your transaction as NOT_SUPPORTED or you could use @Transactional(readOnly=true).


I would say that there is only one solution to this problem: to study. It will be necessary to read books, blogs, magazines or any other trustful source of JPA material. More study is equals to less doubts in JPA.

I am not a developer that believes that JPA it is the only and the best solution to every problem, but there are moments that JPA is not the best to tool to use.

You must be careful when deciding about a persistence framework change, usually a lot of classes are affected and a huge refactoring is needed. Several bugs may be caused by this refactoring. It is needed to talk with the project mangers about this refactoring and list all the positive and negative effects.

In the next four pages we will see 4 persistence frameworks that can be used in our projects, but before we see the frameworks I will show how that I choose each framework.

15 thoughts on “JPA Hibernate Alternatives. What can I use if JPA or Hibernate is not good enough for my project?

  1. The answer is always use the right tool for the job; I doubt you’d find any author of a JPA implementation say different to that.

    Firstly there are many JPA implementations around, and not all have the same problems as Hibernate, some have different ones, depends what your application does as to whether it hits a problem area. Secondly there is JDO, a more capable persistence spec IMHO.

    The real decision is use a persistence API or use JDBC direct; because many of those ‘solutions’ you have there are just JDBC “thin” wrappers.

    • Hello Neil, how are you?

      I love what you said “the right tool”, that is the main idea of this post. [=

      I do believe that most of times we could use a “thin” JDBC wrapper than only JDBC. With a JDBC wrapper we could save development time parsing objects into database data and vice-versa.

      Thanks for passing by

  2. Unfortunately the jOOQ did not work in my PC because my database was too old

    That’s unfortunate, and maybe we should fix that! Even if there is a set of officially supported database versions, jOOQ often also works with older versions. What jOOQ / Database version combination did you use? How did jOOQ not work for you, then? (e.g. code generator? runtime?)

    • Hello Lukas, how are you?

      I cannot remember now what the error was. I remember that it was something related to the MySQL version.

      I wrote this post more than a month ago (in Portuguese first) and I finished the translation 20/aug.

      By the reviews that I saw in forums I have no doubt that jOOQ is a wonderful tool.

      Thanks for the feedback.

    • Mirkus, how are you?

      SpringData is like a Hibernate Wrapper, you would have most o the problems presented here.

      Thank you for passing by

  3. I think it’s unfortunate that development is currently so strongly influenced by corporate agendas. JPA, like many other Java APIs, is the result of a fundamentally wrong way of thinking – thinking that there is a way to build the best solution to any problem using a single language/platform/tool. That’s like thinking a hammer is everything you need in any workshop.

    The old tradition of DSLs, which was commonplace in Unix, is lost. We now try to solve everything with the single language we’re most familiar with. ASP.Net, all previous-gen Java frameworks like struts, tapestry, wicket, even JSP, node.js bringing JavaScript to the server, all database abstraction libraries, be they hibernate or myibatis, are IMO an expression of this way of thinking – which is IMO profoundly wrong. (Just a note on node.js: I don’t think it is a bad idea in itself, I just think there’s way too many cases in which it isn’t used for what it’s best for (i.e. building highly networked and highly dynamic applications by scripting pre-existing components not necessarily written in JavaScript), in scenarios where other technologies would be a better choice.)

    There’s no way you can drive the user interface in a browser from Java as convenient as you can from JavaScript. There’s no way you can do operations in the database as efficiently from Java as you can from stored procedures and triggers written in SQL. Viceversa, SQL is a bad tool for building the domain model of an application, and JavaScript on the server is way behind Java in terms of performance, plus it lacks Java’s type checking, which, in spite of the current popularity of loosely/dynamically typed scripting languages is still very useful even for codebases of just a few thousand lines of code.

    Why am I saying this is a consequence of corporate agendas being pushed by various companies? Very simple. Oracle now/Sun before it have no interest in you using SQL directly – they’d rather have you buy at least support, if not libs and tools, from them or from their partners, and drive the database from Java. The same with MS: why would they want you to stop using their proprietary C#/VB.Net languages in Visual Studio, and start writing JS and HTML with some open source editor? So they go on and popularize ways of development which are convenient to lazy developers, which let you avoid learning multiple languages, and which ideally lock you into a single ecosystem, based on a single language, or at least a family thereof (i.e MS’s .Net platform).

    The best way to develop, but one which requires programmers which are willing to switch languages frequently, ideally even willing and able to develop their own real DSLs, i.e. not just specialized libraries on top of the platform they are using, with parser/lexers and interpreters/compilers, is to develop each part using the technology which is the best fit for it. Build your business logic as a mostly self-contained module/set of modules in Java, C# or whatever compiled language you like, build your persistent model in a relational or non-relational database, whichever is the best fit, expose operations on the persistence layer as stored procedures, use triggers for ensuring its semantic integrity, add a thin layer of glue code, maybe written in some scripting language like ruby or python, use the same scripting language to expose the domain model as REST resources, or write your services in a compiled language, if you think you need the performance increment (which is seldom the case – this part only deals with serialization and deserialization of web requests) and finally but a purely browser-based, single page app on top of it. It may sound complicated, but my experience is that it usually means way less code (like 4-5 times less code), better modularization and way better performance without any specific effort for optimization.

    Smartass improvement: since the domain model changes seldomly (IME), and it’s just the business rules – i.e. the logic of operations which has to be applied to domain objects – that change often, integrate a scripting engine in your domain model, and implement the business logic via scripts. A simple out of the box scripting engine woudl be beanshell for Java, for example. But if your developers don’t shy away from implementing an own DSL, this might be an even better solution.

  4. Great, Great post.

    Unfortunately, the “right tool” is simply not decided. That decision is often based in the expertise of the available manpower and/or the last used tool for an similar job.

    Again, thanks for this post.

Leave a Comment