What is the JPA static metamodel — generated classes such as Customer_ with fields like Customer_.name — how is it produced, and what does it give you over passing attribute names as plain strings?

## The weakness it fixes A criteria query written with strings — `root.get("customer").get("name")` — is not really type-safe. Two things go unchecked: whether the attribute exists, and what Java type it has. Both fail only when the query runs. Worse, `Root.get(String)` returns `Path<Object>`, so the compiler cannot tell you that you just compared a `String` column with an `int`; the builder happily accepts it and the failure appears as a runtime `IllegalArgumentException` or a puzzling SQL type error. ## What the metamodel is JPA defines a **canonical metamodel**: for every managed class `Customer` in package `p`, a class `p.Customer_` annotated `@StaticMetamodel(Customer.class)` with one `public static volatile` field per persistent attribute: ```java @StaticMetamodel(Customer.class) public abstract class Customer_ { public static volatile SingularAttribute<Customer, Long> id; public static volatile SingularAttribute<Customer, String> name; public static volatile SetAttribute<Customer, Order> orders; public static final String NAME = "name"; // Hibernate 6 also emits name constants } ``` The attribute types carry two generic parameters — the owning entity and the attribute's Java type — which is exactly the information the Criteria API needs to type its paths. `SingularAttribute` covers basics and to-one associations; `SetAttribute`/`ListAttribute`/`MapAttribute` cover plural ones; embeddables and mapped superclasses get their own `_` classes, and an entity extending a mapped superclass inherits its metamodel fields. ## How it is produced An annotation processor scans your entities during compilation and writes the `_` classes as generated sources. With Hibernate that is `org.hibernate.orm:hibernate-jpamodelgen`, declared as an `annotationProcessor` (Gradle) or in `maven-compiler-plugin`'s `annotationProcessorPaths`. The static fields are *populated at runtime* by the provider when the `EntityManagerFactory` boots — that is why they are `volatile` and why touching them before the persistence unit starts yields `null`. Practical friction: IDEs need the generated-sources folder marked as a source root, and a clean build is the standard fix for "cannot resolve symbol Customer_". ## Using it ```java Root<Order> o = cq.from(Order.class); Join<Order, Customer> c = o.join(Order_.customer); cq.where(cb.like(c.get(Customer_.name), "A%"), cb.greaterThan(o.get(Order_.total), new BigDecimal("100"))); cq.orderBy(cb.desc(o.get(Order_.createdAt))); ``` Every `get` is typed, so `cb.like` on a non-String path or `cb.greaterThan` on a non-Comparable one is a compile error. Joins are typed too: `o.join(Order_.customer)` returns `Join<Order, Customer>`, so navigation stays checked all the way down. ## Static versus dynamic metamodel JPA also exposes a **runtime** metamodel: `em.getMetamodel().entity(Customer.class).getSingularAttribute("name", String.class)`. Same information, looked up reflectively by string. It is the right tool for generic infrastructure — auditing, generic search layers, tools that do not know your entities at compile time — but it restores exactly the runtime-failure mode the static metamodel removes. Use it deliberately, not as a substitute. ## When it earns its keep The metamodel pays off in proportion to how much criteria code you have. A codebase with a handful of criteria queries can live with strings; one with a real dynamic-search layer, or one that refactors entities regularly, benefits sharply — a field rename turns from a production incident into a red squiggle. It also documents itself: `Customer_.name` in a code search finds every query touching that attribute, which a string literal does not do reliably. The costs are honest but small: an extra build dependency, generated sources in the build directory, an occasional stale-generation confusion after a rename (fix: rebuild), and slightly noisier code. Note also that the metamodel constrains only *your* Java code — it says nothing about column names or the database schema, and it does not make a query correct, only well-typed. ## Gotchas Generated classes are not committed to version control; they are build output. If a `_` class is missing for one entity, the usual cause is a compilation error elsewhere aborting the processor. And Hibernate 6.3+ can additionally generate finder/query methods and String name constants into these classes — handy, but the type-safe attribute fields are the part JPA standardises.