The Java persistence ghetto (and how jOOQ might change that)

This post was originally titled “jOOQ : The good (and bad)”. But we noticed we not only wanted to talk about jOOQ, but also put it into the bigger picture of the Java persistence landscape. Hence, quite a few words about JPA/Hibernate. As a result, you, the reader, will get a nice comparison of the two. Note: Take this post with a bit of humor :)

But first, a tiny detour

We like to offer different opinions at MarcoBehler, and the first one is this: A huge part of the Java community has been living in a ghetto and/or cult and/or comfort zone when it comes to saving their objects to a database. Take for example these phenomena you see over and over again in real life projects:

First, does not matter how much he abuses his database as a stupid data dump and that he ignores those generated 60 table-join sql statements because he never looks at them in the first place, the fashist Java developer needs a structure to be happy:

Have a DAO (abstracting your data access, and yep, just in case, let’s create an interface too, because cglib or javassist are…uhm….weird). Now that we have this sorted out, let’s please use JPA and not Hibernate directly (abstracting away your ORM). Sure, why not hot-swap and A/B-Test your persistence provider and run Hibernate on M(on)T(tue)W(wed) and TopLink on TFSS ;) Ok ok, spring-data-jpa has a few nice points…

And thank god our ORM abstracts away the fact that there is a database in the first place: I don’t have to care about the SQL, my ORM does that for me. And anyway, it’s just a bit of crud. Yeah, right…

Right up comes the belief that the ORM does “magic”. You cannot believe how often we heard “hibernate just did this”. But much more plausible is the fact that you never cared to read the book. Why should you, it’s 880 pages after all and StackOverFlow is just a click away. But even worse, before you should have ever cared to pick up that book and use Hibernate, you should have been *really* comfortable in SQL, which your average Java developer is likely not. For a start, if you want to catch up today, get Markus Wienand’s insanely good book

But what has this got to do with jOOQ?  Alright, alright. Instead of focusing on “standards vs non-standards” or “oo-centric vs database-centric” or any other question we think there should be four simple questions to be answered when thinking about Java database persistence.

 

1. How do I query my DB?

JPQL and the Criteria API are nice tries, but ultimately do not hit it. JPQL sooner or later leads to string replacements or concatenations; Criterias are flexible but easily get out of hand in bigger projects and you really lose the sight of what is being queried. Don’t even get us started on the crimes committed in the name of type safety. Futhermore, as is naturally the case with these kind of standards, those query languages will always lack behind what your database is actually already offering.

jOOQ blows both query languages out of the water. You have your queries easily readable, the flexibility of criteria queries in composing them and best of all: There is (very little) abstraction going on. With jOOQ, you “almost write SQL”. jOOQ simply is a really nice fluent api/DSL/buzzword of the month when it comes to SQL.

2. How do I convert between database <–> objects?

After or before querying the database, the next question is: How do we go from database to objects and vice versa. And Hibernate et. al are really strong here. jOOQ has active records and yep, you can plug in stuff like objectmodelmapper, but mapping with jOOQ does not yet give you this “wow-effect” and feels clumsy at time. Try to get a more complex many-to-many relationship mapped and sooner or later you’ll end up writing some query DTOs and  continue mapping to other objects. This is actually one of our main gripes with jOOQ at the moment.

3. How much other complexity is there (sessions and other goodies)?

The next question no one seems to ask, is if we should deal with the concept of a session (and all surrounding concepts) at all. Do we want to care ab out the lifecycle of an object, detaching, reattaching etc. Are the few advantages enough for the added complexity? Our real life project experiences do not suggest that, on the contrary. In Jooq what you see is (almost) what you get. Very little complexity involved. It makes stuff easier to reason about and that is a big plus for us.

On the other hand jOOQ also feels clumsy at times, especially when it comes to code generation, or more specifically, e.g. when you want to extend your generated POJOs with additional methods etc. Welcome to the world of string manipulation. Maybe something like Square’s Javawriter could make this process a tiny bit better.

4. What does my eco-system look like?

An additional question is of course the eco-system around your persistence tool. Hibernate has quite a few now, most notably hibernate-validator and hibernate-search. And hibernate-search, if used wisely, gives you a nice bang for the buck when it comes to fulltext-search/geolocation etc. jOOQ is somewhat lacking in that retrospect but that has of course nothing to do with jOOQ itself. Still, it will be somewhat detrimental to your productivity.

 

tl;dr: What does this mean?

jOOQ has huge potential and is the long needed fresh breath for the Java persistence world. Still, some improvements need to be made, especially in regards to object mapping and the whole eco-system – which will obivously come with time. If you don’t need all that however, pick it up already! And actually, noone is keeping you from using jOOQ and JPA side by side in the same project.

Other than that the message is: Learn your shit. If you want to use Hibernate or any of the advanced tools, start learning SQL first. Then learn your ORM. And don’t get sucked into the brainless standard debate. As Zed Shaw would say:
Keep programming, mo*****.

 

Want to receive more news that make you a better programmer or help you manage IT projects better?
Sign up for our newsletter!
* = required field
Send me information about...


5 Comments

  1. Thanks for the interesting post! Yes, mapping is something that we have (intentionally) neglected so far, because mapping is a non-issue for purely relational programs that prefer operating on tabular data rather than on object graphs. Nonetheless, people have never listened to Gavin King (claiming that Hibernate is not a replacement for SQL), so why should they listen to us (claiming that jOOQ is not a replacement for Hibernate)? :)

    About the code generation:

    > Welcome to the world of string manipulation.

    Yes, and we prefer to keep it this way for two reasons:

    1. Few people really *need* to adapt the generated output.
    2. We want to be able to generate output other than Java in the future.

    Some users have shown that the code generator can easily be extended using… Xtend (pun not intended), which has a lot of nice templating features.

    > jOOQ is somewhat lacking in that retrospect

    That depends on your point of view. Oracle Text is already natively (and trivially) supported by jOOQ. We personally believe that other types of “search” have been introduced mainly for “me too” and marketing reasons. E.g. Hibernate cannot lose market shares to Elastic Search.

    I’m more than happy to further discuss these things on the jOOQ User Group!

    > noone is keeping you from using jOOQ and JPA side by side in the same project.

    That is really the bottom line! Thanks for pointing that out. We hope to be able to provide a CQRS example soon, where Hibernate / jOOQ cooperate in one application.

  2. Yannick Majoros

    JPA is difficult but complete. It has a learning curve, and you’ll have surprises if you try to shortcut its complexities. But they mostly are there for a reason. Difficult stuff is difficult using JPA, that’s true.

    JOOQ is quick to learn. And is proprietary stuff. Not free. Only one implementation. No public review, only one body involved in its evolution. SQL-oriented, not OO (ok, they say it’s a feature).

    As a serious professional, learn JPA. Fully. There is no excuse for not knowing which sql queries are generated in your production app. Replacing it with a more basic framework is no solution.

    BTW, you lost me at the “fashist” part (and please look the concept up).

  3. Yannick Majoros

    JPA is difficult but complete. It has a learning curve, and you’ll have surprises if you try to shortcut its complexities. But they mostly are there for a reason. Difficult stuff is difficult using JPA, that’s true.

    JOOQ is quick to learn. And is proprietary stuff. Not free. Only one implementation. No public review, only one body involved in its evolution. SQL-oriented, not OO (ok, they say it’s a feature).
    As a serious professional, learn JPA. Fully. There is no excuse for not knowing which sql queries are generated in your production app. Replacing it with a more basic framework is no solution.

    BTW, you lost me at the “fashist” part (and please look the concept up).

Leave a Reply

Your email address will not be published. Required fields are marked *