JPQL et Criteria API

entityManager.find() couvre un seul besoin : retrouver une entité dont on connaît l'identifiant. Tout le reste — chercher, filtrer, trier, agréger, joindre — passe par une requête. JPA en propose deux formes, et le choix entre elles n'est pas affaire de goût.

JPQL est un langage textuel qui ressemble à SQL mais n'en est pas. La différence est fondamentale et se lit dans une seule phrase : JPQL interroge le modèle objet, pas le schéma. Vous écrivez select l from Livre l where l.auteur.nom = :nom, et c'est Hibernate qui décide qu'il faut une jointure sur auteur, avec quel alias, dans quel dialecte. Renommez une colonne dans le mapping et la requête reste valide, parce qu'elle n'a jamais parlé de colonnes.

La contrepartie est qu'une requête JPQL est une chaîne de caractères : le compilateur ne la relit pas. Une faute de frappe sur un nom d'attribut n'apparaît qu'à l'exécution — et si la requête est nommée, au démarrage de l'application, ce qui est déjà mieux. La Criteria API répond exactement à ce problème en construisant la requête par appels de méthodes, vérifiés à la compilation.