Home > Java > No more Hibernate? Really?

No more Hibernate? Really?

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?”
  • 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.

email
Send to Kindle
Categories: Java Tags: , ,
  1. September 23rd, 2013 at 22:41 | #1

    So you finally wrote the article. Indeed, I was expecting more flaming as well. :-)

    Anyway, it’s good to be called “foolish”. It means that the mere idea of challenging de-facto standards is stirring emotions, which was what Hibernate did many years ago.

  2. cblin
    September 24th, 2013 at 15:11 | #2

    IMHO, ORM have values when the programmer understands the associated cost, which is way too often not the case as you said in the article !
    That is, when you use an ORM you must constantly be aware of the queries it will issue for you or you are going to make mistakes …

    Even with seasoned programmers, the @ManyToOne added in a class only to forget that by default it will join the table is a common mistake => it is TOO easy to make a mistake !
    (btw, imho, annotations should require you to specidy what you want to do and not take such a decision for you)

    Regarding jooq and others llike querydsl, the main pitfall I see is for complex business logic, when in the JPA world you are constantly using session cache and even session factory cache to avoid issuing 1000 queries to the db…

    That said, I think that mixing both JPA and sql framewroks is the way to go for JPA3: http://www.querydsl.com/static/querydsl/2.1.0/reference/html/ch02s02.html

    So I guess the conclusion is the same as in any other flame war : use the tools that fits your situation :)

  3. Lol
    September 24th, 2013 at 15:52 | #3
  4. September 24th, 2013 at 18:15 | #4

    @cblin

    which is way too often not the case as you said in the article !

    It is also often not the case for SQL itself. There’s so much one can know about relational databases. Adding JPA on top means adding two layers where developers have to really deepen their knowledge to know what’s going on.

    to avoid issuing 1000 queries to the db

    You’d be surprised how few queries you actually need, if you craft them well with SQL. The main purpose of the session cache is to prevent 1000 unnecessary queries issued by a badly-understood framework. Most of which can be avoided. The few master data queries can be cached manually very easily.

    I think that mixing both JPA and sql framewroks is the way to go for JPA3

    And my take on that is: Now you add a third layer that will obscure things on top of SQL and JPA. Good luck :-)

  5. Octavian
    September 24th, 2013 at 21:09 | #5

    I don’t think there’s anything wrong with JDBC… It’s just a layer of abstraction, a low-level one. Hibernate / JPA is another one, a higher-level one and even more — targeting one (more or less specific) way of developing applications.

  6. cblin
    September 25th, 2013 at 14:43 | #6

    @Lukas Eder

    I think your main point is : the less abstraction you have, the better you are.

    I have to disagree with that point because until the abstraction shomehow “gets in the way”, you are way more productive with it than without it (that is mainly true of all abstractions, otherwise they would not exist in the first place).

    That is, in most enterprise applications, using JPA allows you to implement the CRUD in just a few lines (and CRUD is about 75% of the whole application) : just see below a simplified example taken from my code base !

    Now, I agree that this kind of application is not the only kind of application in the world, but JPA targets this kind of application perfectly IMHO.

    Here is the CRUD example and an example of a problem I often see :
    public class MyObjectDao extends JpaDao {}

    public class MyObjectCRUDServices extends CRUDServices {
    public MyObjectCRUDServices(MyObjectDao dao) { super(dao); }
    //there you MAY have more specific methods unique to the business logic
    }

    The problems with JPA is when you are using “high levels” objects wihtout taking care
    For example : Customer -> Adress -> City -> Country

    You want to list all the premium customer ids and names.
    Considering you are a JPA beginner, you’ll write something like (syntax untested !) :
    public class CustomerServices extends CRUDServices {
    public List findPremiumCustomers() {
    return dao.list(DetachedCriteria.forClass(MyObject.class).add(Property.forName(“premium”).eq(true)));
    }
    }

    Then either you have said @ManyToOne and everything is eagerly fetched so you are joining all the tables and retriveing all the columns and you do not need it.
    Or you have said @ManyToOne(LAZY) and you have a n+1 select problem when you are serializing the objects !

    Now, considering that you are a not a JPA beginner, you’ll write something like :
    public List listPremiumCustomers() {
    return TinyCustomerDto.tranfert( dao.list(DetachedCriteria.forClass(MyObject.class).add(Property.forName(“premium”).eq(true)).addProjectionList(“id, name”)));
    }
    And then the query is the same as I would write myself.

    The problem with the last approach is I have to write quite boring code inside TinyCustomerDto and that the property premium is not typesafe.

    This is where querydsl can be leveraged :
    public List listPremiumCustomers() {
    return dao.list(QMyObject.query().where(QMyObject.premium.isTrue()).list(TinyCustomerDto.class)));
    }
    This is typesafe, readable, efficient (the same query I’ll write myself) AND i have nothing boring to type excpet TinyCustomerDto constructor !

  7. cblin
    September 25th, 2013 at 14:47 | #7

    @cblin
    All the generics have been removed in my comment so it is quite unreadable : sorry !

  8. cblin
    September 25th, 2013 at 16:34 | #8
  9. J_LIKE_Jenkins
    October 11th, 2013 at 09:33 | #9

    You make no mistake that writing/speaking SQL is obviously beyond your current abilities. Sadly, that settles the credibility and objectivity of your analysis. And I pass commenting on you showing off your self-assessed, advanced Hibernate skills. We’ve all chewed that beef, or soon will. In that respect, your post would benefit from a preamble or disclaimer warning that you’re a seasoned right-handed golfer about to tee off with clubs for lefties.

    That being said, I’ll nonetheless bookmark your blog in hopes of future quality material and analyses. For my first impression is that Google stabbed you in the back by referencing this post.

    As for jOOQ: the library is a fresh, albeit bold move with actually steadily growing momentum in my community (statistics/finance). Though I wouldn’t advise it to freshly Java educated programmers geared towards business applications who were taught that RDBMS solely owe their longevity to ORMs and believe that all database schemata follow the same ORM patterns. Rather, jOOQ is proving a nice fit to mathematicians/physicists or engineers with one foot in Java and the head in modeling who are happy to know that their data may be seen through the lenses of different structures and who enjoy type-safety.

    As to those who commented that SQL is ‘low-level': amusing, considering your imperative programming paradigm background.

  1. No trackbacks yet.