borinquenkid opened a new pull request, #16572: URL: https://github.com/apache/grails-core/pull/16572
## What First per-project pull request of the Java-to-Groovy migration tracked in #16351. It transplants the end state of the `9.0.x-java-to-groovy` branch for the Gradle projects under `grails-data-hibernate7/` onto `9.0.x`, unchanged, as four commits in dependency order (one per Gradle project, each compiling on its own): | Commit | Gradle project | Java sources converted | Files changed | Lines | |---|---|---|---|---| | `b9c4e765ac` | `:grails-data-hibernate7-spring-orm` | 24 main | 26 | +1,934 / -2,105 | | `3f3e1c50b4` | `:grails-data-hibernate7-core` | 207 main (+2 new Spock specs) | 265 | +16,534 / -15,717 | | `33c751d633` | `:grails-data-hibernate7-dbmigration-core` (+ RAT config) | 35 main, 19 test, 29 testFixtures | 157 | +6,537 / -6,134 | | `fcf18b26ab` | `:grails-data-hibernate7` (grails-plugin) | 5 main | 6 | +425 / -407 | Total: 454 files, +25,430 / -24,363; 319 `.java` files removed, none left under `grails-data-hibernate7/`. The `dbmigration`, `boot-plugin` and `docs` subprojects were already pure Groovy and are byte-identical to `9.0.x`. Every converted class is statically compiled (`@CompileStatic`; the liquibase-hibernate `HibernateDatabase` family also carries `@POJO` so its public `getProperty(String)` does not become the GroovyObject property hook). `spring-orm` gains the Groovy and code-style plugins so its new sources are compiled and Checkstyle/CodeNarc-checked; `dbmigration-core` drops Lombok (no longer used by the fixtures) and adds `jboss-logging` as `compileOnly` for Groovydoc. ## Why Maintainers asked in #16351 for the migration to land one Gradle project at a time, stacked, instead of as one branch. The Hibernate 7 modules go first because the native domain binding work (#16568) will be rebuilt on top of Groovy sources. The original conversion commits on the umbrella branch are `2416bddc86..0c2e2c2f33` (spring-orm), `98c59ede75..25dde13cd9` (core), `44f4279fa0..e2ba1e6ffe` (dbmigration-core) and `ee295eaabb..06fb6a1c4b` (grails-plugin); their review notes (reference identity in `equals()`, `Optional.map` null-collapse, closure spread, `isX`/`getX` accessor ambiguity, `@POJO` on the liquibase database classes) are summarized in the commit bodies. ## What changed outside the modules Only `gradle/rat-root-config.gradle`: the 47 RAT exclusions that name the liquibase-hibernate fork files (main sources, tests and test fixtures) are repointed from the old `.java` paths to the `.groovy` paths, so the forked third-party files stay excluded and `rat` stays green. No other build logic, settings, CI, docs or skills change. The modules build against the `9.0.x` Java versions of every other module; no class of another module had to come along. ## Verification Local, on this branch (`origin/9.0.x` = `8ef440820e` plus the four commits), one Gradle process at a time, `--no-parallel`: | Run | Result | |---|---| | Per-commit `:<project>:compileGroovy :<project>:compileTestGroovy` (spring-orm, core, dbmigration-core incl. `compileTestFixturesGroovy`, grails-plugin) | all green; the core test compile executed (not from cache) with the default 2 GB forked compiler heap, so no heap override was needed | | Whole-repo `build -PskipTests --continue` | BUILD SUCCESSFUL in 34m 56s, 3446 actionable tasks (3084 executed, 185 from cache, 177 up-to-date), 0 failed tasks; every `grails-data-hibernate7*` compile, `checkstyle*` and `codenarc*` task green | | `codeStyle` | BUILD SUCCESSFUL (1051 tasks, all up-to-date after the build above) | | `rat` | 0 tracked unapproved files; the 2 reported ones are untracked local build artifacts under `grails-data-hibernate7`'s neighbour `grails-data-neo4j/grails-plugin/data/` (`neo4j.key`, `store_lock`), absent on `9.0.x` | Test suites were not run locally for this pull request: the sources are byte-identical to the umbrella branch, whose suites were run on 2026-10-09 (`grails-data-hibernate7-core` 3657 tests / 21 skipped / 0 failures, `dbmigration-core` 40 / 0, `dbmigration` 193 / 0, plugin 41 / 0, whole-repo `build -PskipTests` green). CI runs them here. A javap pass over the 271 converted main classes (reconstructed audit: `ScriptBytecodeAdapter`, `InvokerHelper`, call-site and non-cast `invokedynamic` sites, with the migration's documented exemptions) found no new dynamic dispatch beyond what the umbrella branch already carries: record `equals/hashCode/toString` bootstraps, `as HibernateCallback` coercions (`HibernateTemplate`, `InstanceApiHelper`, `ProjectionPredicate`), lambda bootstraps, the static initializers of the deprecated `HibernateQueryConstants` interface, and five slow-path property writes (`ChildHibernateDatastore.destroy`, `HibernateQuery`'s constructor, `maxResults` and `clone` closure, one `HibernateSession.updateAll` closure, one `HibernateDatastore` multi-tenant closure). They are functionally correct and are left as on the umbrella branch so the later stacked slices apply cleanly. ## Notes - CodeNarc logs an internal `ArrayIndexOutOfBoundsException` from `SpaceAfterOpeningBraceRule` while visiting `core/.../query/SqlRestriction.groovy`; it is a CodeNarc rule bug on a closure expression, not a violation, the task succeeds, and the same message appears when building that file on the `9.0.x-h7-improvement-phase3` worktree. - The `MetaClassRegistryCleaner`-style gotchas (`this == o` in `equals()`, verifier-time class loads from flow typing) that surfaced on the umbrella branch after the merge with `9.0.x` were in `grails-gsp`/`grails-web-url-mappings`, which stay Java here; the Hibernate 7 modules' own equivalent (`SoftKey.equals()` reference identity) was fixed in the original conversion and is included. - After this merges, the next slice should be cut from this branch rather than from `9.0.x` so the stack stays linear. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
