Big Data/Analytics Zone is brought to you in partnership with:

Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 223 posts at DZone. You can read more from them at their website. View Full User Profile

No more Hibernate? Really?

  • submit to reddit


I recently stumbled upon this punchy one-liner: “No More Hibernate!“.

At first, I couldn’t believe what I read. Then, scrolling down, I noticed that the site was linked to jOOQ, a framework that advocates for SQL to have a first-class status in Java:

SQL was never meant to be abstracted. To be confined in the narrow boundaries of heavy mappers, hiding the beauty and simplicity of relational data. SQL was never meant to be object-oriented. SQL was never meant to be anything other than… SQL!

So the jOOQ people do not like Hibernate, EclipseLink and JPA, and prefer writing SQL albeit in Java syntax. I couldn’t swallow this statement and thought about this article. Anyway, its final form is somewhat different from the flaming I originally intended.

I don’t remember fondly the time when I had to write SQL by hand. Perhaps I lost my ability to understand SQL when I understood Object-Oriented Programming? Sure, I wrote once or twice monster PL/SQL scripts, but beyond that, I struggle to write queries with more than 2 joins. And it really bothers me to concatenate strings to create queries with optional parameters.

When I discovered Hibernate – 7 years ago, I could only think: “Wow, these guys understand exactly what is wrong with plain JDBC!”. Since that time, there has been myBatis (formerly iBatis), more Hibernate versions, JPA v1, JPA v2, and so on. It isn’t as if SQL was really welcomed in the Java world… So, who is foolish enough to challenge this?

After letting some background thread digest this “No more Hibernate” stuff, some facts came back to the surface. In particular, do you have ever been in a interview with a candidate proudly displaying Hibernate skills on his CV? For me, it usually goes like this:

  • First question: “Could you describe the reason behind LazyInitializationException?” <blank stare>
  • Second question: “Ok, what’s the difference between eager and lazy loading?” <…>
  • When candidates answer both questions correctly – and that’s not so common, my third question is something along: “What’s your way of avoiding those exceptions?”

At this point, given the fraction of matching candidates, I’m to the point of accepting nearly every answer, even some I’m strongly against, such as the OpenSessionInViewFilter.

Dare I also mention the time I had to review an application code and discovered that each and every attribute was eagerly loaded? Or when I was asked to investigate an OutOfMemoryError in staging but only when logging was activated? Thanks to Dynatrace, I discovered that Hibernate entities all inherited from an abstract class that overrode toString() to use introspection to log every attribute value. To be honest, I had showed this trick to the developer earlier to use when debugging, I wouldn’t have thought he would log entities.

And those are things I know and understand; I’m also aware of more Hibernate’s pitfalls: please check this awesome presentation, by Patrycja Wegrzynowicz to realize its overall scope.

On one hand, Hibernate really rocked the JDBC world, on the other hand, it really set the developer skills bar higher. Even if “No more Hibernate” is really too strong for my own taste, I guess having a look at your team skills and knowledge before choosing your DAO technology stack can go a long way toward meeting your project deadlines and avoiding bad surprises in the later stages.

Published at DZone with permission of Nicolas Frankel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Raging Infernoz replied on Wed, 2013/09/25 - 9:20pm

This plonker thinks I'm a spammer, so I can't post directly hmm...

Anyhow, jOOQ appears to us a Builder pattern which stick too rigidly to SQL so is probably ill suited to most SQL use; however I think all the criticism of the massively bloated (near 70MB!) Hibernate is justified.

I think MyBatis 3 should be considered before Hibernate, because it has a lot of the features, and then some, without the jar and boiler-plate config bloat.  I've even added table and index creation SQL in MyBatis config, and easily called this, after JDBC existence checks, so any argument that it requires an existing database is nonsense.

Oleksandr Alesinskyy replied on Thu, 2013/09/26 - 7:21am in response to: Raging Infernoz

 As for me plain JDBC (preferrably, wrapped into the Spring JdbcTemplate/NamedJdbcTemplate) is OK and sufficient.

As for jOOQ - the idea is quite compelling, unfortunately, the current implementation still generates a semantically incorrect SQL in some cases (e.g. for date/time manipulations).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.