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
