Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Verify native-image behaviour with an end-to-end native build

Aperta
  • Qualcosa non va?
#16,176 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
spring-boot
Ambito
build-system, ci-cd, testing

Direzione di ricerca

Inizia con end-to-end/ e grails-test-examples/aot, poi esamina la copertura esistente di processAot e gli entry point nativeCompile/nativeRun/nativeTest. Aggiungi un target di verifica basato su GraalVM e un workflow attivabile opzionalmente o pianificato; il lavoro è completato quando viene compilato ed eseguito un vero binario nativo e vengono soddisfatte le assertions elencate per plugin/custom i18n e descriptor.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

type: test
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 uses the same hint API Spring Boot uses. Boot's MessageSourceRuntimeHints calls registerPattern (verified in spring-boot-autoconfigure 4.1.0: it references registerPattern, messages.properties and messages_*.properties, and never registerResourceBundle), and this processor does the same. The difference is coverage, not mechanism: Boot registers two hardcoded messages* patterns and derives nothing from the configured base names, whereas this one generates patterns from the effective spring.messages.basename, which is what brings namespaced plugin bundles along.

The open question is only whether the more precise hints.resources().registerResourceBundle(...) would also work. It exists and is the more obvious API for message bundles, yet Boot does not use it. The likely reason is that it serialises to a {"bundle": ...} entry, which GraalVM resolves against the image's included locale set, so non-default locales could drop out — but that is inferred from reading the serialisation code, not documented by Boot or confirmed against a binary. A native test would settle it. If registerResourceBundle turns out to be safe, the hints could become 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.

Lingua principale
Groovy
Stelle
2.9k
Fork
978
Merge medio
1g 2h
PR unite (30g)
183

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/grails-core

Tutte le issue di apache/grails-core

Issue simili

Altre issue su Build System

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.