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 <[email protected]> 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 >
