JPA Criteria API — type-safe queries

JPQL queries are strings — a typo in an entity name won’t surface until runtime. Criteria API offers type-safe queries that the compiler checks at compile time. More verbose, but safer.

Basics¶

CriteriaBuilder for creating queries. CriteriaQuery for defining SELECT. Root for FROM. Predicate for WHERE conditions. TypedQuery for execution.

Metamodel¶

The JPA Metamodel generates static classes (Order_, Customer_) with attributes as typed fields. Instead of the string “orderDate” you use Order_.orderDate. Refactoring an entity automatically reveals broken queries.

Dynamic queries¶

The main strength of Criteria API: dynamically composing queries at runtime. A search form with 10 optional filters — in JPQL you’d be assembling a string. In Criteria API you add Predicate conditions programmatically.

JPQL vs. Criteria API¶

JPQL: more readable for simple queries. Criteria API: safer for complex and dynamic queries. Our rule: JPQL for static queries (@NamedQuery), Criteria API for dynamic search.

Recommendation¶

Use the Metamodel — without it, Criteria API is just more verbose JPQL without the benefits. Generate metamodel classes via the Maven plugin. For static queries, stick with JPQL.