jamesfredley commented on PR #15558:
URL: https://github.com/apache/grails-core/pull/15558#issuecomment-4363845983
## CI fix - 2026-05-02 follow-up
The `Core Projects` job was red on the previous push (`2a5e983555`), but
**not** because of the workaround removals: the failure reproduces against the
unmodified merged tree (verified locally by stashing the audit edits). Root
cause is a separate Groovy 6.0.0-SNAPSHOT regression that arrived between build
#518 and build #546 - the same one I flagged in the previous comment.
### Symptom
```
> Task :grails-data-hibernate5-core:compileGroovy FAILED
HibernateConnectionSourceSettings.java:89: error: clone() in
HibernateSettings cannot override clone() in HashMap
@groovy.transform.Generated() public ...HibernateSettings clone() throws
java.lang.CloneNotSupportedException { return null; }
overridden method does not throw CloneNotSupportedException
```
### Root cause
Groovy 6's Java stub generator now unconditionally emits `throws
java.lang.CloneNotSupportedException` on the `@Generated` `clone()` stub for
any `@AutoClone` target, even when the actual parent's `clone()` doesn't
declare that exception. `HibernateSettings extends LinkedHashMap<String,
String>` and `LinkedHashMap.clone()` drops the throws clause, so javac rejects
the stub as not a valid override.
I confirmed by trying `@AutoClone(style = AutoCloneStyle.COPY_CONSTRUCTOR)`
first - same broken stub, same javac error - so this is in the stub generator,
independent of the @AutoClone style.
### Fix in `4a518983a2`
Defined `clone()` explicitly on `HibernateSettings`. `@AutoClone`
short-circuits its own clone() generation when a user-supplied clone() exists,
so the stub generator emits a stub matching the user-defined no-throws
signature. Body mirrors `@AutoClone(style = CLONE)` to preserve deep-clone of
the typed nested settings (`OsivSettings`, `CacheSettings`, `FlushSettings`,
`additionalProperties`) - this matters for the `getSettings().clone()` call at
`HibernateDatastore.java:597` in `createTenantConnectionSource`, which expects
multi-tenant settings instances to be properly isolated rather than sharing
nested mutable state.
### Local verification on Java 21 / Groovy 6.0.0-SNAPSHOT build #546
```
./gradlew :grails-data-hibernate5-core:compileGroovy --rerun-tasks -> BUILD
SUCCESSFUL
./gradlew :grails-data-hibernate5-core:codeStyle -> BUILD
SUCCESSFUL
./gradlew :grails-data-hibernate5-core:test --tests \
'org.grails.orm.hibernate.connections.HibernateConnectionSourceSettingsSpec'
-> 1
tests, 1 successes, 0 failures
```
### Code style status
`./gradlew codeStyle` was already green on the 5 modules touched by
`2a5e983555` (datamapping-validation, datamapping-core, gsp-core, views-core,
geb). Re-ran on `grails-data-hibernate5-core` after this fix - also green. The
CI failure was pure compile-error, not a code-style violation.
### Next steps
This stub-generator regression should be filed upstream against
apache/groovy with a minimal reproducer (Groovy class with `@AutoClone` +
`extends LinkedHashMap` + a Java consumer in the same compilation unit). The
workaround in `HibernateConnectionSourceSettings.groovy` is documented inline
and explicitly marked removable once upstream lands the stub-generator fix.
PR description updated to add this entry to "Real Groovy 6 regressions, no
upstream PR yet (need to be filed)".
--
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]
