“What Java ORM do You Prefer, and Why?” – SQL of Course!

Catchy headline, yes. But check out this Stack Overflow question by user Mike:

(I’m duplicating it here on the blog, as it might be deleted soon)

It’s a pretty open ended question. I’ll be starting out a new project and am looking at different ORMs to integrate with database access.

Do you have any favorites? Are there any you would advise staying clear of?

And the top voted answer (164 points by David Crawshaw is: “Just use SQL”:

I have stopped using ORMs.

The reason is not any great flaw in the concept. Hibernate works well. Instead, I have found that queries have low overhead and I can fit lots of complex logic into large SQL queries, and shift a lot of my processing into the database.

So consider just using the JDBC package.

The second answer (66 points by user simon) is, again: “Just use SQL”:

None, because having an ORM takes too much control away with small benefits. The time savings gained are easily blown away when you have to debug abnormalities resulting from the use of the ORM. Furthermore, ORMs discourage developers from learning SQL and how relational databases work and using this for their benefit.

The third answer (51 points by myself) is saying, once more: “Use SQL” (and use it with jOOQ).

The best way to write SQL in Java

Only the fourth answer (46 points by Abdullah Jibaly) mentiones Hibernate, the most popular ORM in the Java ecosystem.

The truth is, as we’ve shown numerous times on this blog: Hibernate/JPA/ORMs are good tools to get rid of boring (and complex) CRUD. But that’s just boilerplate logic with little value to your business logic. The interesting stuff – the queries, the batch and bulk processing, the analytics, the reporting, they’re all best done with SQL. Here are some additional articles:

Stay tuned as we’re entering an era of programming where object orientation fades, and functional / declarative programming makes data processing extremely easy and lean again.

6 thoughts on ““What Java ORM do You Prefer, and Why?” – SQL of Course!

    • Yannick, your comment was as well timed as it was expected.

      However, I do invite you to join one of my SQL Masterclasses. I am convinced I will be able to show you how beautiful SQL is, and why so many other people have been upvoting the answers that encourage using SQL.

  1. ORM tools are as great as you manage to use them properly. There are projects where ORM tools work like a charms, while in others, they don’t fit well at all. In the end, it’s the development team responsibility to choose the right tool for their project requirements.

    ORM tools are complex. Unfortunately, only a part of all developers will spend time to understand how they work. The rest will just blame the tool and say it’s bad.

    The question is: Does the most upvoted answer offers the best advice?

    So consider just using the JDBC package.

    Do we really want to use plain JDBC? Why? I’d choose Hibernate or jOOQ any time over plain JDBC.

    The next answer is not really true either:

    Furthermore, ORMs discourage developers from learning SQL and how relational databases work and using this for their benefit.

    Hibernate has been offering the SQLQuery API from the very beginning. In fact, [Gavin Kind (the creator of Hibernate) said it very clearly](https://www.reddit.com/r/programming/comments/2cnw8x/what_orms_have_taught_me_just_learn_sql/cjheyec):

    I’m inclined to blame development teams who use a relational database, but decide they don’t need to hire an experienced DBA, or an expert data modeler. But then I also realize that there is fault on both sides of this divide: relational database experts have traditionally been extremely insensitive to the needs of the application side, and have shown little interest in familiarizing themselves with ORM technology. Which leaves them unable to really provide useful advice to the application programmers. Sad.

    Most of the people who blame Hibernate will blame the next data access framework if they don’t take time to master SQL, JDBC or any RDBMS-specific peculiarities.

    • Thank you very much for your feedback.

      JDBC can be a great fit in some environments. It has zero overhead and sometimes you can easily live with string-based SQL. Perhaps, add some tiny API on top of it to ease the pain of checked exceptions and indexed bind variables and ResultSet to List mapping, but that’s it.

      I completely agree with Gavin again (already had at the time). It is sad indeed. Many comments in this discussion (https://redd.it/4rc9uu) about understanding JOINs by understanding cartesian products are equally sad. A lot of people prefer to go through the path of least resistance, deferring thinking about stuff properly until much later in the project, when it’s too late to make fundamental decisions.

      Which is, after all, why we do make a living as consultants and experts, though. Right? 🙂

      • Even worse, some people will just “assume” how SQL, ORM, or any other framework works and never invest time to check if those assumptions are actually true.

        For all these reasons, I’m very confident that there will be a high demand for SQL, RDBMS, and Data experts many years from now. If Jim Grays’ papers from 1976 are still relevant today, there is a good chance that SQL is going to be relevant even 40 years from now.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s