Introduction to JPA and Hibernate

A relational database thinks in rows, columns, and foreign keys. A Java program thinks in objects, references, and inheritance. These two models don't line up: a Java reference is a pointer in memory, while a foreign key is a copied value; a Java object can inherit, while a table cannot. This gap has a name, the object-relational impedance mismatch, and all the work you used to do by hand with JDBC — copying columns into fields, finding an already-loaded object so you don't duplicate it, deciding when to write — amounts to bridging it.

JPA is the Jakarta EE platform's standardized answer to this problem. Hibernate is its most widely used implementation, and by far the oldest: Hibernate existed before JPA, and JPA was largely designed on the basis of it. The result, for you, is an ORM that lets you write commande.getClient().getNom() instead of a join, and that decides on its own when the UPDATE is sent to PostgreSQL.

That delegation is precisely what makes the subject difficult. An ORM doesn't eliminate SQL, it produces it for you. The day a page that displayed fifty orders issues fifty-one queries instead of two, the problem isn't in your code: it's in a decision Hibernate made, based on annotations you wrote without measuring their effect. This course is built around that scenario, known as the N+1 query problem. It shows up in this very lesson, it happens right before your eyes in the lesson on relationships, and it is cleanly resolved in the optimization lesson.