The GitHub Actions job "CI" on grails-core.git/grails8-groovy6-canary has succeeded. Run started by GitHub user jamesfredley (triggered by jamesfredley).
Head commit for run: 8af3b23216a6fdd317541cbddb847a6130ffe7b4 / James Fredley <[email protected]> docs: drop incorrect GROOVY-11829 citation from GormEntity workaround comments The GROOVY-11829 cross-reference in three places turned out to be the wrong JIRA: https://issues.apache.org/jira/browse/GROOVY-11829 is "Properties located from a set(key, value) always use the same method even when the value type is better matched by another" - resolved 2026-01-01, fix version 6.0.0-alpha-1, and entirely about set(...) overload selection, not the get(...) dispatch behaviour we work around in GormEntity. Re-checked the actual mechanism on apache/groovy master HEAD `f5ab762500` (committed 2026-04-25 15:06 UTC, 11 minutes before the snapshot we test with): private static boolean isGenericGetMethod(MetaMethod method) { if (method.getName().equals("get")) { CachedClass[] parameterTypes = method.getParameterTypes(); return parameterTypes.length == 1 && parameterTypes[0].getTheClass() == String.class; } return false; } So the genericGetMethod selection still requires String.class. The regression we hit was a different one entirely: a trait-static get(String) is picked up by the *implementing class's* MOP as a candidate for instance-property generic-getter dispatch, returning a GormStaticApi where propertyMissing should produce a DelegatingGormEntityApi. There is no upstream Apache Groovy JIRA we could find for this dispatch behaviour at the time of writing. Update the three citations to: * GormEntity.get(Serializable) docstring: drop the relaxed-isGenericGetMethod story (it never happened), describe the actual symptom (instance-MOP picking up the trait-static get on @Entity classes, Hibernate "Unknown entity: java.util.LinkedHashMap"), point at the GormEntityTransformation AST shim as the home of the fix, and note that no upstream JIRA is filed. * GormEntityTransformation: same symptom narrative, drop the GROOVY-11829 reference, add an explicit "remove this once an upstream JIRA is filed and fixed (or once Spock 2.x ships a Groovy 6-compatible artifact and we re-validate)" pointer. * GormEntityTransformSpec: rename the feature method to "test Groovy 6 generic-getter instance-dispatch guard" (no JIRA in the title) and rewrite the docstring to match. Verified locally: ./gradlew :grails-datamapping-core:test \ --tests 'org.grails.compiler.gorm.GormEntityTransformSpec' -> 9 tests, 0 failures, BUILD SUCCESSFUL ./gradlew :grails-datamapping-core:codenarcMain \ :grails-datamapping-core:codenarcTest -> BUILD SUCCESSFUL No production-code behaviour changed; this is purely the comment / docstring / spec-method-name cleanup pass. Assisted-by: claude-code:claude-opus-4-7 Report URL: https://github.com/apache/grails-core/actions/runs/24943880678 With regards, GitHub Actions via GitBox
