Grails 9 now tracking Groovy 6 beta – status, p riorities, and call for coordinated work before GA

Hi all,

I wanted to give both the Groovy and Grails communities a clear status 
update and a call to action.

Current status

Grails 9 is now building and publishing snapshots against Groovy 6. The 
key merge landed here:

https://github.com/apache/grails-core/commit/cd062bf7c6051bff0622118367c8d2ddf23955ec

Snapshots are available (see the recent announcement on the lists). We 
are intentionally staying close to the Groovy 6 betas so that Grails 
remains one of the largest real-world test cases for the language.

Groovy 6 is already at beta-2. It may need one more beta or could move 
to RC1 relatively soon. That means the window for any remaining changes 
we need, for Grails 9, in Groovy 6 itself is closing.

Timeline goal

The target is to have Apache Groovy 6.0.0 out before Community Over Code 
in Glasgow (11–14 October). We then want Grails 9.0.0 ready very shortly 
afterward — ideally in milestone or RC form around the conference, with 
a full 9.0.0 release based on Groovy 6 within a week or two of the 
Groovy GA.

Grails and Groovy are sister projects under the ASF. Grails is one of 
the most widely used applications of the language and a comprehensive 
integration test suite (the monorepo now contains essentially the full 
kitchen sink). Historically we have been forced into extreme or breaking 
workarounds well after Groovy 4 and 5 reached GA. This time we want to 
surface and resolve anything that actually needs to change in Groovy 6 
before 6.0.0 ships.

Workarounds and remaining items

All of the compatibility adjustments we had to make are tracked and 
documented:

- https://github.com/apache/grails-core/issues/16157 (Groovy 6 
compatibility changes required in Grails, and when each can be removed)

- https://github.com/apache/grails-core/issues/16161 (Micronaut island 
currently excluded)

If anyone cares about a specific item listed in those issues and 
believes it should be fixed or improved on the Groovy side rather than 
adjusted to breaking changes in Grails, the path is:

1. Create a ticket in the Groovy JIRA.
2. Open a pull request against a fork of the Apache Groovy repository.

I am personally only going to prioritize work that impacts the end 
application that users actually run. Framework-internal or 
optional-integration items that do not affect that surface are lower 
priority for me personally.

Micronaut integration

The Micronaut island is currently disabled in the Grails build so that 
we can publish usable Groovy 6 snapshots. The root cause is the usual 
dense compatibility matrix (Grails + Spring + Spring Framework + 
Micronaut + Java version + Groovy version). Someone who uses the 
Micronaut integration and wants it working on Grails 9 will need to 
invest the time to sort it out.

There is already movement toward extracting that code into its own 
repository under the Apache organization (grails-micronaut). Once that 
happens it will no longer be part of the single Grails monorepo build 
and can choose its own Groovy and Java versions independently. That 
extraction should make the work easier for whoever picks it up. I do not 
plan to spend time on it myself.

Invokedynamic / call-site caching

I have opened an initial pull request to enable Indy by default on Grails 9:

https://github.com/apache/grails-core/pull/16165

In Groovy 6 the classic (non-invokedynamic) call-site classes under 
`org.codehaus.groovy.runtime.callsite` have been moved out of core into 
the optional `groovy-callsite` module (GROOVY-12185). Core now uses 
invokedynamic by default (as it has since Groovy 4). The classic types 
are deliberately not marked `@Deprecated` in the current betas so that 
downstream projects such as Grails can validate Indy performance without 
noise. Javadoc already indicates they are planned for deprecation and 
eventual removal in a future release; formal deprecation may still 
appear before 6.0.0 GA depending on beta feedback.

Micro-benchmarks look favorable for Indy. Full application HTTP 
benchmarks on Grails are usually comparable and sometimes slightly 
slower, which tells us there are still places in the Grails codebase 
that are not using Groovy in the most performant way under the Indy 
path. Those are the kinds of adjustments I intend to focus on.

What I am asking for

- If you see something in the Grails workarounds that really belongs as 
a change (or clarification) in Groovy 6, please raise it in the Groovy 
JIRA and, if you can, submit a PR while we still have beta runway.
- Volunteers who care about the Micronaut integration are welcome to 
take that on (including moving to its own repository under Apache 
(grails-micronaut).
- Sister projects and downstream consumers should start tracking the 
Groovy 6 betas in parallel so we are not discovering major issues after GA.

Everything required for the current Grails 9 + Groovy 6 combination is 
already visible in the grails-core repository. The more we can clear 
before Groovy 6.0.0, the cleaner the GA experience will be for both 
communities.

Thanks for the continued collaboration.

James Fredley
Vice President & PMC Chair, Apache Grails