Hibernate 7 Support by jdaugherty · Pull Request #15530 · apache/grails-core

jdaugherty · 2026-03-23T15:29:39Z

I accidentally pushed to 8.0.x-hibernate7 instead of 8.0.x-hibernate7-bom. This caused #15510 to close as a result.

From that PR's todos:

Current Progress:

Fixing bad merges of the gradle plugin extraction
Fixing license headers
Fixing styling
Attempted merge of code styles
Running CI against hibernate 7 branch
Splitting boms into a hibernate5 & 7 bom (probably needs more work)

TODO:

docs need further updates
several functional tests were added for hibernate 5 and not copied to the hibernate 7 - @jamesfredley
we need to diff the hibernate 5 functional tests with hibernate 7 to see if any were subsequently changed - @jamesfredley
functional tests in hibernate 7 should use the hibernate 7 bom.
grails-datamapping-core changes need to be looked at closer; I might have merged these the wrong way. - @jamesfredley

I am opening this PR to track the status of Hibernate 7 merge to 8.x.

Some notes from previous meetings on the Hibernate 7 Upgrade:

HibernateQuery is the core class, GormDetachedCriteria is now inside of it & this class no longer uses an abstract builder pattern. This does mean we need an active connection to create a query.
HibernateCriteriaBuilder was changed to HibernateQuery - purpose was to build query components & run separately
Domain Binding was changed to no longer use a monolithic class. Now, "GrailsDomainBinder" is instead a thin wrapper around the root binder implementation.

# Conflicts: # gradle.properties # grails-datamapping-core/src/main/groovy/org/grails/datastore/gorm/GormEntity.groovy # grails-doc/src/en/ref/Database Mapping/insertable.adoc # grails-doc/src/en/ref/Database Mapping/updatable.adoc # grails-test-suite-uber/build.gradle

getBinders() now accepts an optional collector parameter (defaulting to getCollector()) so callers can pass a pre-created collector, ensuring second-pass registrations made during bindRoot are visible to the same collector used in the test body. CollectionBinderSpec, ListSecondPassBinderSpec and MapSecondPassBinderSpec received the same fix. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> # Conflicts: # grails-data-hibernate7/core/src/main/groovy/org/grails/orm/hibernate/cfg/domainbinding/binder/GrailsPropertyBinder.java # grails-data-hibernate7/core/src/main/groovy/org/grails/orm/hibernate/cfg/domainbinding/binder/SingleTableSubclassBinder.java # grails-data-hibernate7/core/src/main/groovy/org/grails/orm/hibernate/cfg/domainbinding/binder/UnionSubclassBinder.java

…patch Extract bindCollectionSecondPass into focused private methods: - bindOneToManyAssociation: handles OneToMany collection setup - applyMultiTenantFilter: applies tenant filter condition - bindCollectionKey: handles bidirectional/unidirectional key binding - bindCollectionElement: dispatches element binding by property type - bindManyToManyElement: typed ManyToMany element binding - bindBidirectionalMapElement: typed bidirectional map element binding Replace ManyToOneBinder.bindManyToOne(HibernateAssociation) with two typed overloads that eliminate instanceof guards: - bindManyToOne(HibernateToOneProperty): handles direct to-one associations; extracts bindOneToOneUniqueKey for the OneToOne case - bindManyToOne(HibernateManyToManyProperty): handles inverse side of ManyToMany; extracts prepareCircularManyToMany Add HibernateManyToManyProperty.getHibernateInverseSide() covariant override returning HibernateManyToManyProperty, enabling CollectionSecondPassBinder to call the typed overload without a cast. Update ManyToOneBinderSpec to call typed overloads directly (removing 'as HibernateAssociation' casts). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…) checks with instanceof

…oncrete types; eliminate OneToOne cast and HibernateToOneProperty overload

…ve it from bindProperty, bindComponent, bindClassProperties, and bindCompositeId method signatures

…eToOneBinder

…ty> in ManyToOneBinder

…ionSecondPassBinder

…nto CollectionKeyBinder

…ementBinder

…TableBinder

…yInverseValuesBinder

…ToManyProperty

…Datastore

When actionName is null and no id is present, append the controller token so that <g:form controller="foo"> (no action) generates /foo instead of an empty string. Preserve existing behaviour when an id is present and no action is given (id-only URL patterns such as /$id? still resolve correctly without prepending the context controller name). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The 'many-to-many queries with sorting do not throw exception' feature (issue #14636) now passes on Hibernate 5 as well. Remove the @PendingFeatureIf guard and the unused IgnoreIf/PendingFeatureIf imports. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

fix: add Groovy proxy support to HibernateProxyHandler.isInitialized()

Fixed regressions from Hibernate 5

testlens-app · 2026-04-04T03:37:23Z

✅ All tests passed ✅

🏷️ Commit: e2d9374
▶️ Tests: 339 executed
⚪️ Checks: 31/31 completed

Learn more about TestLens at testlens.app.

jdaugherty · 2026-04-04T03:41:10Z

build-logic/plugins/src/main/groovy/org/apache/grails/buildsrc/GrailsTestPlugin.groovy

+import org.gradle.api.tasks.testing.Test
+import groovy.transform.CompileDynamic
+
+class GrailsTestPlugin implements Plugin<Project> {


I mentioned this on the dev PR thinking we still had a root aggregation project, but I don't see one other than grails-data-test-report.

Shouldn't we remove this. Add a generic grails-test-report and instead use the testReportAggregation Gradle plugin (like grails-data-test-report already does)? This way we get caching and we don't implement our own?

@matrei what are your thoughts here?

The recent updates to the build logic, particularly the GrailsTestPlugin and GrailsCodeStylePlugin, are designed to shift quality feedback "left"—moving it from the CI environment directly to the developer's local workflow.

Developer-Centric Aggregation: Unlike standard build reports that focus on overall success/pass rates, these plugins are failure-focused. They are specifically designed for developers to identify and resolve blockers across a complex multi-module project without sifting through massive logs.

Immediate Feedback Loop: With the new aggregateStyleViolations and aggregateTestFailures tasks, developers no longer need to wait for a full CI pipeline execution to see the total impact of their changes.

Unified Issue Tracking: The plugins consolidate errors from various tools (CodeNarc, Checkstyle, PMD, SpotBugs, and JUnit) into centralized Markdown reports (TEST_FAILURES.md, CODENARC_VIOLATIONS.md, etc.) at the project root. This provides a single source of truth for all outstanding issues that need addressing before a push. These files are already ignored for check in.

Automated Remediation: To further speed up the development cycle, the code style plugin includes a codenarcFix task that automatically repairs common formatting regressions, ensuring the branch remains compliant with project standards with minimal manual effort.

Line 33 indicates that this is a root project task that configures the test task. My assumption is you're running this at the root. How is this different than using the test aggregation plugin then? Can you help me understand how this workflow is expected to be used?

Before pushing run it from root pickup all test failures locally. My pain point is making changes in core and not seeing breaks in hib 5.

build-logic/plugins/src/main/groovy/org/apache/grails/buildsrc/SbomPlugin.groovy

buildSrc/src/main/groovy/grails/doc/macros/HiddenMacro.groovy

gradle.properties

# Conflicts: # NOTICE # dependencies.gradle # gradle/publish-root-config.gradle

…ibernate7 # Conflicts: # .idea/codeStyles/Project.xml # NOTICE # build-logic/plugins/build.gradle # dependencies.gradle # gradle/publish-root-config.gradle

jdaugherty · 2026-04-09T17:58:00Z

build.gradle

 import org.apache.tools.ant.taskdefs.condition.Os

 ext {
+    if (file('local.properties').exists()) {


Is this necessary? What is this being used for?

local overrides as an option for command line parameters.

We should move this to our SharedProperties plugin then so it's consistently applied.

Actually, are you aware that any gradle property can be overridden by environment variable? i.e. 'foo' , set ORG_GRADLE_foo and it will be set that way.

jdaugherty · 2026-04-09T17:58:16Z

build.gradle

            cacheChangingModulesFor(cacheHours, 'hours')
        }
    }
+    pluginManager.withPlugin('jacoco') {


We should be configuring this in build-logic

I agree, that is a leftover from working in the module

jdaugherty · 2026-04-09T19:52:55Z

It's my understanding that Walter is working on the spring orm split like we did on the hibernate 5 code. Once that's done, I'll make another pass at the build/license logic then finally review the hibernate code.

borinquenkid · 2026-04-10T02:39:16Z

It's my understanding that Walter is working on the spring orm split like we did on the hibernate 5 code. Once that's done, I'll make another pass at the build/license logic then finally review the hibernate code.

@jamesfredley @jdaugherty PR15567

This comment has been minimized.

Sign in to view

borinquenkid and others added 28 commits March 23, 2026 13:28

Introduce HibernateEnumProperty marker interface; replace isEnumType(…

f910c02

…) checks with instanceof

refactor isValidHibernateOneToOne and isValidHibernateManyToOne

e753e65

Clean up GrailsPropertyBinder/ManyToOneBinder/OneToOneBinder to use c…

bb09c7a

…oncrete types; eliminate OneToOne cast and HibernateToOneProperty overload

Move InFlightMetadataCollector into ComponentBinder constructor; remo…

4edc9aa

…ve it from bindProperty, bindComponent, bindClassProperties, and bindCompositeId method signatures

refactor methods into HibernateOneToOneProperty

16b4923

refactor: split ManyToOneBinder into ManyToOneBinder and ForeignKeyOn…

4d86dcb

…eToOneBinder

refactor: replace isCompositeIdentifier with Optional<CompositeIdenti…

c96bf2d

…ty> in ManyToOneBinder

refactor: CompositeIdentifierToManyToOneBinder

1c1dc23

test OrderByClauseBuilder

bfbde3a

refactor CollectionSecondPassBinder

85c0aac

refactor CollectionSecondPassBinder

b53527e

Extract bindOrderBy into CollectionOrderByBinder

d13a8d9

refactor: extract bindOrderBy and applyMultiTenantFilter from Collect…

8f37cd3

…ionSecondPassBinder

refactor: extract bindCollectionKey from CollectionSecondPassBinder i…

1da3398

…nto CollectionKeyBinder

refactor: extract bindBidirectionalMapElement into BidirectionalMapEl…

b24db91

…ementBinder

refactor: extract bindManyToManyElement into ManyToManyElementBinder

4a28b19

refactor: move DependantValue creation into CollectionKeyBinder

08e1e86

refactor: HibernateToManyProperty.getCacheUSage

63b2488

refactor: move CollectionKeyBinder into CollectionKeyColumnUpdater

3d80db3

efactor: extract BasicCollectionElementBinder from CollectionWithJoin…

b92f0b1

…TableBinder

refactor: move ManyToOne element creation into UnidirectionalOneToMan…

b9933d0

…yInverseValuesBinder

refactor: extract resolveJoinTableForeignKeyColumnName into Hibernate…

c3356b1

…ToManyProperty

refactor: create SimpleValue inside of simpleValueColumnBinder

9cdb1d3

refactor(hibernate7): merge AbstractHibernateDatastore into Hibernate…

3f90467

…Datastore

Fixed SubqueryAliasSpec

1ebdbca

rename for Hibernate7OptimisticLockingSpec

62a1500

borinquenkid and others added 7 commits April 3, 2026 09:05

Merge branch '8.0.x-hibernate7' into 8.0.x-hibernate7-dev

78b8b36

H7: fix style violations and update agent guidelines

1497ea4

H7: update agent guidelines for test aggregation

9d723a8

H7: make test aggregation more robust by scanning all root directories

d52a9e5

Merge pull request #15548 from apache/fix/groovy-proxy-isinitialized

6cc9fda

fix: add Groovy proxy support to HibernateProxyHandler.isInitialized()

This comment has been minimized.

Sign in to view

Merge pull request #15550 from apache/8.0.x-hibernate7-dev

e2d9374

Fixed regressions from Hibernate 5