You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@grails.apache.org by James Daugherty <jd...@apache.org> on 2026/06/16 13:06:46 UTC
[DISCUSS] Micronaut Abandonment
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
Re: [DISCUSS] Micronaut Abandonment
Posted by Sergio del Amo <se...@softamo.com>.
There are two flavours of the Micronaut HTTP Client. One based on Netty, One based on the built-in JDK HTTP Client. There are same features only supported by the Netty version but most people would not need those features.
> On 17 Jun 2026, at 00:34, Jochen Theodorou <bl...@gmx.org> wrote:
>
> Hi,
>
> I am asking mostly because I may get questions and would like to be able to answer them... At the same time I am too much out of the loop to know any details and afaik it changed a lot in recent versions. And since a wider discussion was encouraged:
>
> How does the Netty dependency materialize? Is it in Micronaut because of the http client? How does it come in, in case of Spring? And most importantly, are those required dependencies. For example Micronaut http client could work with a different dependency.
>
> Or is it more than just Netty, when it comes to version problems with micronaut and Netty was just the most outstanding one.
>
> Furthermore... what is the actual story for the user for having Grails on top of Micronaut in the first place if Grails does not plan to go away from Spring to Micronaut? It is not like a Grails app can then suddenly, auto-magically be compiled to a native image. Is it reusing Micronaut code? I also have the feeling this story changed over time.
>
> Also while I see Micronaut in a side repository as well, since there is a lack of manpower and interest, I don't see how that can solve the situation of conflicting Netty versions in any way. Isn't it more likely such a Grails-Micronaut is in the long-term forced to "fork" Grails and make a Grails specific to Micronaut, giving up on Spring mostly? Or what do you expect how does will develop if there is a champion? Managing expectations is important.
>
> bye Jochen
>
> On 6/16/26 15:06, 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
>
Re: [DISCUSS] Micronaut Abandonment
Posted by Gianluca Sartori <g....@gmail.com>.
Err... my bad, just to make it clear, I was not part of the decision, I am
just a Grails user at the moment.
But I did not understand the rationale behind that decision, I think there
must be good reasons to add any dependency, especially when they add 100Mb
to the final jar and increase the costs of maintaining the whole project.
A part of me is still fighting to not complain more than I am already doing
:)
Gianluca Sartori
--
https://dueuno.com
On Wed, 17 Jun 2026 at 12:38, Jochen Theodorou <bl...@gmx.org> wrote:
>
>
> On 6/17/26 10:22, Gianluca Sartori wrote:
> >>
> >> Furthermore... what is the actual story for the user for having Grails
> >> on top of Micronaut in the first place if Grails does not plan to go
> >> away from Spring to Micronaut?
> >>
> >
> > That was my question at the beginning of the new Grails community driven
> > process, the reason was mostly due to the better HttpClient that
> Micronaur
> > had at the time.
>
> I did read the 2024 voting on github yesterday. The declarative client?
> Wasn't that already done with in Grails 7?
>
> > Now we (finally) have a ton of them in Spring and Apache for any level of
> > abstraction you need/prefer to make a service call.
> >
> > And BTW, my work has been very much inspired by the Grails & Micronaut
> > developers and I am a fan of the people who brought Groovy & Grails to
> the
> > universe.
> > But the architect in me is kicking my balls every time he can for the
> > decision of including Micronaut (which I love and appreciate) in Grails.
>
> Being a software architect also means to review decisions and correct
> them. So do not kick too hard. Believe me, I did some things in Groovy I
> am not happy with today and try to fix them in the long term.
>
> But what I get is: there is no real justification left for having
> Micronaut in Grails from a technical perspective.
>
> bye Jochen
>
Re: [DISCUSS] Micronaut Abandonment
Posted by Jochen Theodorou <bl...@gmx.org>.
On 6/17/26 10:22, Gianluca Sartori wrote:
>>
>> Furthermore... what is the actual story for the user for having Grails
>> on top of Micronaut in the first place if Grails does not plan to go
>> away from Spring to Micronaut?
>>
>
> That was my question at the beginning of the new Grails community driven
> process, the reason was mostly due to the better HttpClient that Micronaur
> had at the time.
I did read the 2024 voting on github yesterday. The declarative client?
Wasn't that already done with in Grails 7?
> Now we (finally) have a ton of them in Spring and Apache for any level of
> abstraction you need/prefer to make a service call.
>
> And BTW, my work has been very much inspired by the Grails & Micronaut
> developers and I am a fan of the people who brought Groovy & Grails to the
> universe.
> But the architect in me is kicking my balls every time he can for the
> decision of including Micronaut (which I love and appreciate) in Grails.
Being a software architect also means to review decisions and correct
them. So do not kick too hard. Believe me, I did some things in Groovy I
am not happy with today and try to fix them in the long term.
But what I get is: there is no real justification left for having
Micronaut in Grails from a technical perspective.
bye Jochen
Re: [DISCUSS] Micronaut Abandonment
Posted by Gianluca Sartori <g....@gmail.com>.
>
> Furthermore... what is the actual story for the user for having Grails
> on top of Micronaut in the first place if Grails does not plan to go
> away from Spring to Micronaut?
>
That was my question at the beginning of the new Grails community driven
process, the reason was mostly due to the better HttpClient that Micronaur
had at the time.
Now we (finally) have a ton of them in Spring and Apache for any level of
abstraction you need/prefer to make a service call.
And BTW, my work has been very much inspired by the Grails & Micronaut
developers and I am a fan of the people who brought Groovy & Grails to the
universe.
But the architect in me is kicking my balls every time he can for the
decision of including Micronaut (which I love and appreciate) in Grails.
Gianluca Sartori
--
https://dueuno.com
>
> bye Jochen
>
> On 6/16/26 15:06, 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
>
>
Re: [DISCUSS] Micronaut Abandonment
Posted by Jochen Theodorou <bl...@gmx.org>.
Hi,
I am asking mostly because I may get questions and would like to be able
to answer them... At the same time I am too much out of the loop to know
any details and afaik it changed a lot in recent versions. And since a
wider discussion was encouraged:
How does the Netty dependency materialize? Is it in Micronaut because of
the http client? How does it come in, in case of Spring? And most
importantly, are those required dependencies. For example Micronaut http
client could work with a different dependency.
Or is it more than just Netty, when it comes to version problems with
micronaut and Netty was just the most outstanding one.
Furthermore... what is the actual story for the user for having Grails
on top of Micronaut in the first place if Grails does not plan to go
away from Spring to Micronaut? It is not like a Grails app can then
suddenly, auto-magically be compiled to a native image. Is it reusing
Micronaut code? I also have the feeling this story changed over time.
Also while I see Micronaut in a side repository as well, since there is
a lack of manpower and interest, I don't see how that can solve the
situation of conflicting Netty versions in any way. Isn't it more likely
such a Grails-Micronaut is in the long-term forced to "fork" Grails and
make a Grails specific to Micronaut, giving up on Spring mostly? Or what
do you expect how does will develop if there is a champion? Managing
expectations is important.
bye Jochen
On 6/16/26 15:06, 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
Re: [DISCUSS] Micronaut Abandonment
Posted by Søren Berg Glasius <so...@glasius.dk>.
From a user and consultant perspective, I think dropping the Micronaut
support is the right call, though I say it with a heavy heart.
My client does not know about this discussion yet, but I am pretty sure
they will understand the reality of the situation. While they will not be
thrilled to see it go (we will particularly miss the Micronaut HTTP
Client), we have already spent a significant amount of time trying to get
the integration to work smoothly in our own environments, and the
bean-configuration with external-config continuously fail to work.
Seeing the breakdown of the dependency conflicts, the Java 21 vs. 25
divergence, and the resulting CVE risks makes it clear that fighting this
uphill battle is unsustainable for the core team. We cannot sacrifice the
security and stability of the framework for a high-maintenance feature with
low adoption.
Regarding the timeline, I agree with James's approach of releasing it as-is
in 8.0.0 to give remaining users a transition runway, but effectively
dropping support and freezing further updates unless an outside champion
steps up. Personally I do not have the clock-cycles to champion the Grail
Micronaut Plugin.
Thanks to James Fredley and James Daugherty for all the heavy lifting you
have done on this so far.
Den tirs. 16. jun. 2026 kl. 18.31 skrev Gianluca Sartori <
g.sartori@gmail.com>:
> I believe Grails 8 should decouple itself from Micronaut.
>
> Beyond all the points already raised, I don't see a strong architectural
> justification for including Micronaut in Grails. I genuinely appreciate the
> excellent work being done by the Micronaut team, but unless the intention
> is to make Grails a Micronaut-based framework—which feels like a discussion
> for another time and another reality—its integration introduces complexity
> with limited benefit.
>
> For that reason, I think dropping Micronaut support is the right decision.
>
> Gianluca Sartori
> --
> https://dueuno.com
>
>
> On Tue, 16 Jun 2026 at 15:06, James Daugherty <jd...@apache.org>
> 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
> >
>
--
Best regards
Søren Berg Glasius
Apache Groovy™ and Apache Grails® PMC
--- Press ESC once to quit - twice to save the changes.
Re: [DISCUSS] Micronaut Abandonment
Posted by Gianluca Sartori <g....@gmail.com>.
I believe Grails 8 should decouple itself from Micronaut.
Beyond all the points already raised, I don't see a strong architectural
justification for including Micronaut in Grails. I genuinely appreciate the
excellent work being done by the Micronaut team, but unless the intention
is to make Grails a Micronaut-based framework—which feels like a discussion
for another time and another reality—its integration introduces complexity
with limited benefit.
For that reason, I think dropping Micronaut support is the right decision.
Gianluca Sartori
--
https://dueuno.com
On Tue, 16 Jun 2026 at 15:06, James Daugherty <jd...@apache.org> 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
>
Re: [DISCUSS] Micronaut Abandonment
Posted by James Daugherty via dev <de...@grails.apache.org>.
I strongly disagree with quickly sunsetting hibernate 5 or deciding on
it so quickly. It's already split out and works without the build
modifications that micronaut requires - ideally we want anything in
our repo that's easy to maintain. We should release hibernate with
support in 8.x and then evaluate what we do with Grails 9 (spring boot
5). The difference between micronaut and hibernate is that micronaut
is causing a substantial amount of work that conflicts with the other
dependencies and leads to a completely insecure Grails app. Hibernate
hasn't had that problem. Personally, I think we should leave
hibernate 5 support as optional in 9 (default to hibernate 7 in 9)
because it's a major change and then remove it when we do Spring Boot
6.
For micronaut, my proposal is to release it in 8, but then do no
further releases unless we have someone to support it. I'm suggesting
we effectively drop support for it after the initial 8.0.x release.
-James
On Tue, Jun 16, 2026 at 11:34 AM Walter Duque de Estrada
<wb...@icloud.com> wrote:
>
> Thanks for outlining the challenges with Micronaut so clearly. Rather than moving it to a side repository immediately, I propose a phased sunsetting strategy. I also think we should include Hibernate 5 (h5) in this exact same plan.
>
> Here is my proposed path:
>
> Grails 8.0.x: Micronaut and h5 are kept in the build. It is uncomfortable but manageable. We accept patches only.
>
> Grails 8.1.x: They are kept in the codebase historically, but are strictly unmaintained.
>
> Grails 9.0.x: Micronaut and h5 are completely removed.
>
> This approach gives any remaining users a predictable runway while immediately reducing our maintenance burden so we can focus on core priorities like the Hibernate 7 migration.
>
> What does the team think
>
> Thanks,
>
> Walter
>
>
> > On Jun 16, 2026, at 8:06 AM, James Daugherty <jd...@apache.org> 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
>
Re: [DISCUSS] Micronaut Abandonment
Posted by Walter Duque de Estrada <wb...@icloud.com>.
Thanks for outlining the challenges with Micronaut so clearly. Rather than moving it to a side repository immediately, I propose a phased sunsetting strategy. I also think we should include Hibernate 5 (h5) in this exact same plan.
Here is my proposed path:
Grails 8.0.x: Micronaut and h5 are kept in the build. It is uncomfortable but manageable. We accept patches only.
Grails 8.1.x: They are kept in the codebase historically, but are strictly unmaintained.
Grails 9.0.x: Micronaut and h5 are completely removed.
This approach gives any remaining users a predictable runway while immediately reducing our maintenance burden so we can focus on core priorities like the Hibernate 7 migration.
What does the team think
Thanks,
Walter
> On Jun 16, 2026, at 8:06 AM, James Daugherty <jd...@apache.org> 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
Re: [DISCUSS] Micronaut Abandonment
Posted by Walter Duque de Estrada <wb...@icloud.com>.
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 <ja...@apache.org> 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
>>
Re: [DISCUSS] Micronaut Abandonment
Posted by James Fredley <ja...@apache.org>.
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
>
Re: [DISCUSS] Micronaut Abandonment
Posted by Gianluca Sartori <g....@gmail.com>.
+1 (preview)
Gianluca Sartori
--
https://dueuno.com
On Sun, 23 Aug 2026 at 18:47, James Daugherty via dev <de...@grails.apache.org>
wrote:
> This topic came up again this week: while trying to test Grails with
> Groovy 6 (to ensure we can have a smooth upgrade when it releases).
> Micronaut releases don't currently have any such support and fail on
> Groovy 6. I'd like to start a vote thread on moving the Micronaut
> related functionality out of grails-core into its own repo so it
> doesn't continue to hinder Grails Version upgrades. Not just because
> of the Groovy version, but it's a real problem that we have to choose
> between libraries that Micronaut upgrades vs Spring upgrades. We've
> already had to make decisions related to CVEs that could leave
> applications vulnerable.
>
> I'd like to propose we do this as of Grails 8 - so have it working for
> the initial Grails 8 release, and then rely on the community if
> support continues. If we can get support, then we can continue to
> support it in a laggard manner, but I don't want it to hold back
> Grails.
>
> On Wed, Jun 17, 2026 at 10:03 AM James Fredley <ja...@apache.org>
> wrote:
> >
> > At the end of the day, someone that uses Micronaut in Grails will have
> to step up to maintain it. It will be moving off grails-core into it's own
> repo. James and I have put hundreds of hours into this and we are unsure
> that more than 1 company is using it, given only one stated that it was
> broken months after the Grails 7 release. The Spring Boot solution works
> great for the declarative http client.
> >
> > 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
> > >
>
Re: [DISCUSS] Micronaut Abandonment
Posted by Walter Duque de Estrada <wb...@icloud.com>.
Abandon Micronaut
Walter
> On Aug 23, 2026, at 11:47 AM, James Daugherty via dev <de...@grails.apache.org> wrote:
>
> This topic came up again this week: while trying to test Grails with
> Groovy 6 (to ensure we can have a smooth upgrade when it releases).
> Micronaut releases don't currently have any such support and fail on
> Groovy 6. I'd like to start a vote thread on moving the Micronaut
> related functionality out of grails-core into its own repo so it
> doesn't continue to hinder Grails Version upgrades. Not just because
> of the Groovy version, but it's a real problem that we have to choose
> between libraries that Micronaut upgrades vs Spring upgrades. We've
> already had to make decisions related to CVEs that could leave
> applications vulnerable.
>
> I'd like to propose we do this as of Grails 8 - so have it working for
> the initial Grails 8 release, and then rely on the community if
> support continues. If we can get support, then we can continue to
> support it in a laggard manner, but I don't want it to hold back
> Grails.
>
> On Wed, Jun 17, 2026 at 10:03 AM James Fredley <ja...@apache.org> wrote:
>>
>> At the end of the day, someone that uses Micronaut in Grails will have to step up to maintain it. It will be moving off grails-core into it's own repo. James and I have put hundreds of hours into this and we are unsure that more than 1 company is using it, given only one stated that it was broken months after the Grails 7 release. The Spring Boot solution works great for the declarative http client.
>>
>> 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
>>>
Re: [DISCUSS] Micronaut Abandonment
Posted by James Daugherty via dev <de...@grails.apache.org>.
This topic came up again this week: while trying to test Grails with
Groovy 6 (to ensure we can have a smooth upgrade when it releases).
Micronaut releases don't currently have any such support and fail on
Groovy 6. I'd like to start a vote thread on moving the Micronaut
related functionality out of grails-core into its own repo so it
doesn't continue to hinder Grails Version upgrades. Not just because
of the Groovy version, but it's a real problem that we have to choose
between libraries that Micronaut upgrades vs Spring upgrades. We've
already had to make decisions related to CVEs that could leave
applications vulnerable.
I'd like to propose we do this as of Grails 8 - so have it working for
the initial Grails 8 release, and then rely on the community if
support continues. If we can get support, then we can continue to
support it in a laggard manner, but I don't want it to hold back
Grails.
On Wed, Jun 17, 2026 at 10:03 AM James Fredley <ja...@apache.org> wrote:
>
> At the end of the day, someone that uses Micronaut in Grails will have to step up to maintain it. It will be moving off grails-core into it's own repo. James and I have put hundreds of hours into this and we are unsure that more than 1 company is using it, given only one stated that it was broken months after the Grails 7 release. The Spring Boot solution works great for the declarative http client.
>
> 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
> >
Re: [DISCUSS] Micronaut Abandonment
Posted by James Fredley <ja...@apache.org>.
At the end of the day, someone that uses Micronaut in Grails will have to step up to maintain it. It will be moving off grails-core into it's own repo. James and I have put hundreds of hours into this and we are unsure that more than 1 company is using it, given only one stated that it was broken months after the Grails 7 release. The Spring Boot solution works great for the declarative http client.
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
>