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

Hello, how are you?

Today we will talk about situations that 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. [=

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