Thanks James D. and James F.
To move this forward, I am calling for consensus on a revised plan based on our
discussion. While James F. and I are aligned on moving Micronaut, I need to
clarify the architectural reality of the datamapping layer and why keeping
Hibernate 5 fully supported is unfeasible.
To be precise: the datamapping core is performing okay right now after the
recent O(M+N) fix that has not been approved yet. However, the architecture is
highly brittle because it relies heavily on subclassing, which breaks
encapsulation.
I want to rewrite this foundation to establish a strict contract with
consistent interactions. We need this clean, interface-driven architecture to
easily bring in Elasticsearch, would be a massive boon for the framework.
Here is the proposed roadmap for consensus:
Datamapping Core & Hibernate Strategy
A. The Core Evolution: The datamapping layer is moving away from the
brittle subclassing model to a clean, contract-driven architecture that can
easily support integrations like ES and H7.
B. Grails 8.x: H5 is deprecated. Ensuring backwards compatibility for an
EOL framework tethered to the old inheritance model is a massive time sink that
actively blocks our progress.
C. Grails 9.x: H5 is completely removed.
I cannot spend the next six months dragging an EOL module through a fundamental
architectural cleanup. We need to drop it so we can build a clean, extensible
datamapping layer and unlock Elasticsearch.
Please come to the Grails meeting to discuss this
Walter
> On Jun 16, 2026, at 3:15 PM, James Fredley <[email protected]> wrote:
>
> Thank you for the excellent summary. Moving grails-micronaut to a side repo
> is the right path, then just need to decide on 8.1.x or 9.0.x for that split.
>
> James Fredley
>
> On 2026/06/16 13:06:46 James Daugherty wrote:
>> Hi Everyone,
>>
>> For the last 2 weekly meetings we have discussed the problems of
>> integrating Micronaut & Spring. Both James Fredley & I have spent a
>> significant amount of time ensuring Micronaut continues to work with
>> Grails. While we have a solution for Grails 8, we don't think we can
>> continue this support without a champion to help in this area. Here
>> are the problems we've encountered:
>>
>> 1. Micronaut & Spring are updating dependencies at a different pace.
>> This is really our core issue. For example, in Spring Boot 3.5.x
>> Netty was updated to 4.1.x, while Micronaut jumped to 4.2.x. These
>> version mismatches introduce hard incompatibilities which makes us
>> choose which framework to prefer. Because Spring chose the lower
>> version, we were forced to choose Netty 4.1.x, which meant that the
>> Micronaut version had to be kept at a lower version. During 8.0's
>> development, this was even more extreme due to the Micronaut 5.x
>> development.
>>
>> 2. The downgrading of dependencies means CVEs in our dependent
>> libraries often will exist and we will be unable to update. This is a
>> huge blocker for us. We can't release insecure software. Without
>> members on either the Micronaut or Spring teams, we can't really help
>> resolve these issues. Micronaut has been helpful in updating
>> libraries when we request, but we don't think it's reasonable to ask
>> them to downgrade - we're not involved in their framework development.
>>
>> 3. Micronaut made the decision to jump all the way to Java 25 in
>> Micronaut 5, even though 21 is still supported. Spring made the
>> decision to support all the way back to 21. We had discussed going to
>> 25, but we wanted to choose the minimum JVM version that would be
>> supported for the life expectancy of Grails 8 (so we chose 21). This
>> means that the micronaut portions of our build have to be built with
>> Java 25, while the rest is built with Java 21. This is another huge
>> issue for us because the ASF Security team requires reproducible
>> builds. Which means a significant amount of work had to go into our
>> verification process to support this divergence.
>>
>> 4. We have not seen significant contributions to the Micronaut support
>> in Grails. Only James Fredley & James Daugherty have been evolving
>> it. Without a champion to help with these problems, we are spending
>> too much of our time on Micronaut and not enough on other core
>> priorities (i.e. Hibernate 7).
>>
>> 5. We believe there are a low number of users still using the
>> Micronaut support and thus the effort to continue this support is
>> higher than the reward.
>>
>> This email is meant to start a wider discussion: we want to move the
>> micronaut support into a side repository. If we can find a champion
>> to help maintain it, then we can keep publishing it separate from
>> Grails. Otherwise, we will eventually archive that integration and
>> abandon it.
>>
>> -James
>>
