codeconsole opened a new issue, #16176:
URL: https://github.com/apache/grails-core/issues/16176
### Background
Grails 8 now has a native-image build path: #16094 added `processAot`
wiring, cooperation with `org.graalvm.buildtools.native`, and the
`GenerateNativeMetadataTask` / `TraceNativeMetadataTask` machinery, and #16102
moved i18n onto Spring Boot's `MessageSource` with an
`I18nRuntimeHintsProcessor` that registers resource hints for the effective
`spring.messages.basename`.
What neither PR established is a build that actually **compiles a native
binary and runs it**. Today:
- nothing in the repository invokes `nativeCompile`, `nativeRun` or
`nativeTest`;
- no CI workflow provisions GraalVM or mentions native-image;
- `grails-test-examples/aot` verifies `processAot` output and a JVM startup
check, both of which run on a normal JDK.
So every native-image claim in the framework currently rests on JVM-level
AOT processing plus reasoning about the metadata, rather than on a binary that
was built and exercised. That is a reasonable place to have landed the feature
work, but it leaves a gap worth closing deliberately.
### Proposal
Add a native-image verification target — most likely under `end-to-end/`,
since it already consumes published artifacts — that builds a real GraalVM
binary from a Grails application and asserts runtime behaviour that only a
native image can falsify.
Suggested first assertions, ordered by how likely they are to catch
something:
1. **Plugin message bundles resolve.** A namespaced plugin bundle (for
example `spring-security-core_fr.properties`) resolving in the binary. This is
the case Spring Boot's own `MessageSourceRuntimeHints` does not cover — it
registers two hardcoded `messages*` patterns and derives nothing from the
configured base names — so if `I18nRuntimeHintsProcessor` is wrong, plugin
messages resolve on the JVM and silently vanish in native.
2. **A base name the application configured itself resolves**, e.g.
`spring.messages.basename: config/i18n/custom`, covering the dot-to-slash path
conversion.
3. **The i18n descriptor is readable**, since base-name discovery reads
`META-INF/grails/i18n.properties` through an exact-name
`ClassLoader.getResources` lookup at runtime.
4. Whatever equivalent assertions the AOT cache and native metadata work
from #16094 would want.
### Open question worth settling with the test
`I18nRuntimeHintsProcessor` registers resource **patterns** rather than
calling `hints.resources().registerResourceBundle(...)`. That follows Spring
Boot's own choice for this case — its registrar uses `registerPattern` even
though the bundle-specific API exists — on the theory that a `{"bundle": ...}`
entry resolves against the image's included locale set and can drop non-default
locales. That is a design signal, not something anyone has verified. A native
test would settle it, and if `registerResourceBundle` turns out to be fine, the
hints could be made more precise.
### Notes
- This is framework-wide infrastructure, not specific to i18n: a native job
would serve the AOT cache work, GORM, GSP and anything else that ships hints.
- Cost is the main design question. A full `nativeCompile` is minutes of CPU
and needs a GraalVM toolchain, so it probably belongs on a scheduled or opt-in
workflow rather than every PR.
Raised from review discussion on #16102.
--
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]
