I dont think it is true that everyone hates JPA/Hibernate. I dont hate them and dont know many people IRL who hate them. I know SQL, worked with SQL before Hibernate. Here, developers are expected to learn SQL even as project is using Hibernate.

For me, migration to Hibernate was improvement. There is a subculture of people who hate Hibernate, hate Java, hate frameworks for anything. And some of these people are very vocal and emotional about it. And then there is everybody else.

And a lot of it honestly sounds like projection. People who dont like to have to learn these things and quite clearly did not bothered to learn them. They assume Hibernate is used to avoid learning SQL, because that would make sense to them. But, back in real java world, developers are expected to know both.

Yeah, I don't hate JPA/Hibernate. I fact, I tend to hate its absence, because for me that's usually meant a four user CRUD app written with JDBC and a billion lines of boilerplate mapping between the domain and SQL CRUD statements.

I mean, there are definitely cases where JPA/Hibernate doesn't fit for all kinds of reasons, but don't avoid it where it does help (e.g. the 4 user CRUD app that needs to be "web scale").

Gosh has it been 15 years already? I never liked Java much. But several companies I liked and hired me where using mostly that. Then I did some consulting / freelancing / firefighting. ORM and mostly Hibernate was often a topic.

My experience and methodology is as follow :

- Write test for your ORM layer. Possibly not in Java. Some high level integration type test. ( calling your web-layer or API and checking for what comes out )

- Burn your ORM layer down.

- Have someone who know the business logic sit with you. And re-write the ORM layer from mostly scratch.

- While doing the above, train that person on the very redondant gotcha ( Inverse n to n, accidental carthesian product, bad ID generation, compulsive flush, un-needed @lazy or @eager to deal with performance, @embedded abuse and fucked up SQL schema because of the previous)

- Train all dev on the persistence lifecycle of stuff in JPA. "No, most likely you won't have to call .persist or .merge yourself" being the bottomline

- Have a shiny documented exemple of 1 to 1, N to 1, N to N examples ( both with or without inverse link )

- If some report or API needs a fucked up SQL query with 18 join. Write that thing in native SQL and shove it in your DAO. You don't need to mess up you'r whole DAO layer for those 3 queries

- Pray

- Run the test from step 1.

--- TL;DR : if the ORM layer is somewhat clean. you can mostly forget about it. On the project I'm on now, I did not had to touch it more than once in 2 years. ( and that was terrible, granted, we touched a test and stuff that had nothing to do with it started to blow up. But still, once in 2 years is not a lot )

Both JOOQ and JDBI are superior to JPA in my book.

jOOQ is the most obvious contender. Since I use Java I like type safety, jOOQ gives me that (like Hibernate) without trying to abstract the fact that I make queries to a db (which Hibernate does).

jOOQ and JPA doesn't solve the same problem.

That's why JOOQ is superior.

It depends on what you want to do.

Complex queries with multiple joins? jOOQ.

Persist changes to complex aggregate models with multiple layers of child entities? JPA/Hibernate.

> Doctor, it hurts when I do this. Then don't do that

The interesting part is how to perform updates without an ORM. All this "just use SQL" statements seem to ignore this problem. If a domain model is used there is no simple, obvious way how to find out what needs to be updated in the database and how to generate performant SQL code from it. I'm really interested in some examples how to do it.

> “You don’t need an ORM, write your own SQL queries directly and create a beautiful domain driven design object model” leads straight into a project only the owner will understand

Could you please elaborate why will this end up happening?

I've been on projects that had ~50 active contributors. All of them used plain SQL queries and used a library (don't remember which) only to map columns to Java types. Everyone understood table structure they were working on and its relationship with other tables. If they introduced a new query they were expected to run 'explain plan' first to understand the consequences and change the query if needed. I won't deny that it all needed a bit of shepherding by the senior engineers but the overhead was negligible. As an upside every developer was always up to date with the schema and precisely knew the performance consequences.

The mess you state is perhaps a byproduct of "get-big-fast" code bases?

How do you deal in such a project with similar queries that fetch not all the same data?

E.g. Query A retrieves an Author and a count of all the boks he has written. Query B retrieves an author and the title of the most recent book he has written. I see following options: - make two models, one for each query -> leads to a lot of similar models and code-bloat - make a base query and fetch additional data with an additional query -> leads to a lot of small queries that would sometimes be more performant as a single query

Shameless plug : for a little while now I've been working on a project with others to try a different approach. We use a higher level abstraction that does a better job of modeling the data than language-level objects. This eliminates the impedance mismatch. Because it's not language dependent you can use the same models (we call them "logical objects") with multiple languages.

The logical objects are hierarchical and serialize easily to JSON and back, making it simple to write REST interfaces. There are a couple of production teams making good use of it.

Github repo is here; feel free to contact me about it: https://github.com/zeidon/zeidon-joe

Nice, had a poke around, found a small typo while reading about it

Asynchronous loads are trivial with Zeidon. Simply add the “.synchronous” qualification to the activate.

Thanks! It's on the list :)

Exactly! And can you even call yourself an experienced Java developer if you haven't written your own ORM at some point?

I just don't understand this mind set. Just learn SQL and not only is it not hard to maintain SQL, you'll find its so much easier to manipulate data.

Just get something like JDBI for the row set to POJO mappings.

C# have micro-ORMs like Dapper, surely Java has smth similar? Micro-ORMs show the SQL but the object generation still gets done for you so you get a bit of both worlds.

I wouldn't call it micro, but https://ebean.io/ is pretty nice.