[borinquenkid]

Depends on #16572 (the Hibernate 7 modules converted to Groovy): this branch is based on refactor/java-to-groovy-grails-data-hibernate7, so until #16572 merges the diff shown here includes it. Once it merges, the diff shrinks to the 113 commits of this PR. The two follow-ups are stacked on it: native binding as the default, then the deletion of the classic binder.

What

GORM for Hibernate 7 gains native domain binding: a GrailsDomainGenerator turns an already-built GORM PersistentEntity into a JPA/Hibernate-annotated carrier class, and Hibernate's own annotation binder binds it. Sessions, queries and proxies keep using the real domain classes (the carrier's entity name, cache regions and class-loader lookups all resolve to the real class). In this PR it is opt-in (hibernate.generatedDomainClasses: true); the next PR in the stack makes it the default, and the last one deletes the hand-built GrailsDomainBinder.

Where to start reading

Native domain binding replaces GrailsDomainBinder building Hibernate's boot model by hand (about 5,800 lines that re-implement what Hibernate's annotation binder already does): GORM generates a JPA-annotated class for each domain class from its evaluated mapping and lets Hibernate's own annotation binder bind it. The application's real domain classes remain what Hibernate persists, loads, queries and proxies; the generated classes exist only while the mappings are bound.

The code lives in one package, org.grails.orm.hibernate.cfg.domainbinding.jpa, with the value records in the subpackage jpa.facets. Reviewing it is easiest in the order the binding runs:

1. The switch. HibernateConnectionSourceSettings reads hibernate.generatedDomainClasses. When it is on, HibernateMappingContextConfiguration creates a GeneratedDomainClassBinder and gives it to GrailsDomainBinder, which hands the entities to it instead of binding them itself. (From Hibernate 7: delete the classic domain binder #16570 on there is no switch: GormMappingContributor always hands the entities to the generated-class binder.)
2. The entry point. GeneratedDomainClassBinder.contribute is called by Hibernate while it collects mappings. It asks GrailsDomainGenerator.generateAll for an annotated class per entity and gives those classes to Hibernate's annotation binder. Its second half, getSessionFactoryBuilder, runs once the metadata is complete and points every bound entity at the real domain class, its property accessors and GORM's identifier generator.
3. The decisions. GrailsDomainGenerator is where every mapping rule lives. It reads a GrailsHibernatePersistentEntity (properties plus the evaluated mapping and constraints blocks) into the records of jpa.facets, which state what to bind (columns, types, ids, associations, collections, inheritance, caches, tenancy, natural ids, indexes, unique keys), and then writes those facets as JPA and Hibernate annotations with ByteBuddy. A mapping it cannot describe is refused up front, by entity and property name, through supports and unsupportedReason, before Hibernate boots. This is the large class; it will be split into per-concern collaborators once the classic binder is gone, so that its diff stays reviewable against the binder it replaces.
4. Class loading. GeneratedDomainClassLoader resolves a domain class name to the generated class while Hibernate binds the mappings. Because a class loader answers a name the same way forever once Class.forName has been asked, the switch to the real classes is made by GeneratedDomainClassLoaderService, which swaps to a second service whose loader resolves the same names to the application's classes.
5. GrailsIdGenerator is a marker annotation carrying the GORM id generator strategy and its parameters, since GORM's generators cannot be named through Hibernate's @IdGeneratorType.

How it is verified. The specs under grails.gorm.tests.generated run the same behaviour through both bindings. Two differential specs compare, for every scanned test domain class (about 1,170 entities and 3,400 properties), what the generator states against what the classic binder bound, both at the Hibernate boot-model level and at the DDL level. The classic side is frozen as recorded data under src/test/resources/classic-oracle, so the comparison survives the removal of the classic binder in #16570. The whole core suite also runs through the generated classes.

The same reading order is in the package-info of the jpa package and in the hibernate-developer skill.

Why

The classic binder re-implements Hibernate's boot model by hand (~5,800 lines) and has been the source of a steady stream of mapping defects (seven of them fixed on 8.0.x during this work: #16520, #16522, #16523, #16524, #16531, #16532, #16533, #16539). Letting Hibernate bind the entities removes that layer; the GORM mapping DSL stays the public surface.

Scope

• grails-data-hibernate7/core, package org.grails.orm.hibernate.cfg.domainbinding.jpa: GrailsDomainGenerator (ByteBuddy; every mapping option the classic binder honours, incl. composite identifiers via @IdClass, embedded types, all three inheritance strategies, multi-tenancy, natural ids, caches, custom and converting types, custom collection types), GeneratedDomainClassBinder (AdditionalMappingContributor plus an aligner that reproduces the classic binder's naming and DDL decisions where Hibernate's defaults differ), GeneratedDomainClassLoader[Service].
• ManyToManyOwnerValidator: a bidirectional many-to-many with belongsTo on neither side now fails at startup (MappingException) instead of silently never being written; on 8.0.x the same case logs a warning (Hibernate 7: warn when a many-to-many has no belongsTo on either side #16532).
• Envers: a generated entity carries a JPA @Version, which Envers would skip; the optimistic-lock column is audited as before unless the application sets org.hibernate.envers.do_not_audit_optimistic_locking_field itself.
• Tests: 26 both-modes specs under grails.gorm.tests.generated, the whole core suite runnable through the generated classes (-Pgrails.test.generatedDomainClasses=true), and two differentials that compare native binding with the classic binder over every scanned test domain class (1,169 entities, 3,381 properties: 0 mismatches; DDL: 85 known differences, 0 unknown, 0 refused). The classic side of both differentials is frozen as recorded data (src/test/resources/classic-oracle/), so they survive the deletion of the classic binder.
• Docs: new chapter Native Domain Binding in the GORM for Hibernate 7 manual (what stays the same, what changes in behaviour and schema, switching an existing database, Envers, the one unsupported mapping and its workaround), configuration reference, Hibernate 7 migration checklist, and the Grails 8 → 9 upgrade notes (upgrading90x.adoc §1).

Also in this PR, because the branch has to pass the repository's CodeNarc rules: the grails-startup-progress sources that arrived from upstream in Java are converted to Groovy, and intentionally empty catch parameters are named ignored in seven modules.

Behaviour changes for applications (all documented in the upgrade notes)

• A many-to-many without an owning side fails at startup.
• With native binding on: a custom UserCollectionType on a hasMany of entities takes effect (the classic binder ignored it); a shared embedded collection gets a table per owner; an embedded object as a part of a composite identifier is refused with a message pointing at the documented flattening workaround; a handful of schema differences listed in the manual (for example check (idx >= 0) on list index columns).

Verification

Every module of grails-data-hibernate7 in both modes at the tip of this PR: core 4,813 tests (classic default) and 4,523 (generated), dbmigration-core 40, dbmigration 110 + 93 CLI, plugin 39 + 2, spring-boot 2, all green; both differentials as above; codeStyle clean; docs built.

Merge of the Java-to-Groovy review follow-up (#16572)

This branch now contains the reviewed #16572 (merged up the stack), including 9.0.x with the upstream fixes #16533 (unique groups on enum and collection properties) and #16539 (nested composite foreign key column order).

• GrailsDomainGenerator follows the classic binder for both: it states the unique group of an enum property (UniqueKeyFacets is now record UniqueKeyFacets(name, columns); the bound flag is gone) and orders a nested composite foreign key's columns, and the columns they reference, by identifier property name.
• The frozen classic oracle (ddl-differential.txt, generator-differential.txt) is refrozen from the classic binder for the fixtures that came with 9.0.x; 48 existing records changed, consistent with Hibernate 7: unique groups on enum and collection properties #16533/Hibernate 7: name nested composite foreign key columns in the referenced key's order #16539.
• Removed the three "known difference" rows in the native binding guide and the upgrade-guide bullet that described differences which no longer exist. The Hibernate 7 section of the upgrade guide is now 2.x (9.0.x added a GPars section as 1).
• Verified at the tip: core 4,967 tests, plugin 39, dbmigration-core 41, 0 failures; codeStyle clean.

[borinquenkid]

BLOCKER before merge: this branch carries a temporary CI commit.

This PR is stacked, and to avoid starting a full CI matrix on every push or rebase of the stack it carries one temporary commit, CHANGEME FOR ACCEPTANCE: disable PR workflow triggers. It changes the pull_request: trigger of 13 workflows to branches: ['CHANGEME-FOR-ACCEPTANCE'], a branch that does not exist, so pushing, rebasing or force-pushing this branch starts no jobs.

Condition for merging this PR: that commit must be reverted on this branch first, and CI must then run and be green. The absence of CI checks on this PR is deliberate and does not mean the code was tested. The full build runs on #16576 and #16572, the PRs that target 10.0.x.

[testlens-app]

🔎 No tests executed 🔎

🏷️ Commit: 686239a
▶️ Tests: 0 executed
⚪️ Checks: 46/46 completed

---

Learn more about TestLens at testlens.app/docs.