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*****.
Don`t miss out!
Want to receive more news that make you a better programmer or help you manage IT projects better? Sign up for our newsletter!