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

Sormula

Sormula is a ORM OpenSource framework, very similar to the JPA/Hibernate.

The code of the project in this page can be found in here: https://github.com/uaihebert/SormulaCrud

Sormula has a class named Database that works like the JPA EntityManagerFactory, the Database class will be like a bridge between the database and your model classes. To execute the SQL actions we will use the Table class that works like the JPA EntityManager, but the Table class is typed.

To run Sormula in a code you will need to create a Database instance:

Sor01

To create a Database instance all that we need is a Java Connection.

To read data from the database is very easy, like below:

Sor02

You only need to create a Database instance and a Table instance to execute all kind of SQL actions.

How can we map a class attribute name different from the database table column name? Take a look below:

Sor03

We can use annotations to do the database mapping in our classes, very close to the JPA style.

To update, delete or create data in the database you can do like below:

Sor04

Sor05

Sor06

About Sormula we can say that:

  • Has a good documentation

  • Easy to set up

  • It is not found in the maven repository, it will make harder to attach the source code if needed

  • Has a lot of checked exceptions, you will need to do a try/catch for the invoked actions

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