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
