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

Spring JDBC Template

One of the most famous frameworks that we can find to access the database data is the Spring JDBC Template.

The code of this project can be found in here:

The Sprint JDBC Template uses natives queries like below:


As it is possible to see in the image above the query has a database syntax (I will be using MySQL). When we use a native SQL query it is possible to use all the database resources in an easy way.

We need an instance of the object JDBC Template (used to execute the queries), and to create the JDBC Template object we need to set up a datasource:


We can get the datasource now (thanks to the Spring injection) and create our JDBCTemplate:


PS.: All the XML code above and the JDBCTemplate instantiation could be replace by Spring injection and with a code bootstrap, just do a little research about the Spring features.

One thing that I did not liked is the INSERT statement with ID recover, it is very verbose:


With the KeyHolder class we can recover the generated ID in the database, unfortunately we need a huge code to do it.

The other CRUD functions are easier to use, like below:


Notice that to execute a SQL query it is very simple and results in a populated object, thanks to the RowMapper. The RowMapper is the engine that the JDBC Template uses to make easier to populate a class with data from the database. Take a look at the RowMapper code below:


The best news about the RowMapper is that it can be used in any query of the project. The developer that is responsible to write the logic that will populate the class data.

To finish this page, take a look below in the database DELETE and the database UPDATE statement:



About the Spring JDBC Template we can say:

  • Has a good support: Any search in the Internet will result in several pages with tips and bug fixes.

  • A lot of companies use it: several projects across the world use it

  • Be careful with different databases for the same project: The native SQL can became a problem with your project run with different databases. Several queries will need to be rewritten to adapt all the project databases.

  • Framework Knowledge: It is good to know the Spring basics, how it can be configured and used.

To those that does not know the Spring has several modules and in your project it is possible to use only the JDBC Template module. You could keep all the other modules/frameworks of your project and add only the necessary to run the JDBC Template.

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