Replies: 4 comments 5 replies
-
I am all for progress and moving forward to using Java 21 already, and the arguments for doing so are quite compelling. That being said, I would be very cautious about dropping support for Java 17. This kind of move could potentially scare away a lot of folks who thrust to have some sort of stability in using the combo Java 17+ Micronaut. If you want to do it at least gather a larger consensus from the user base; a poll here with just a handful of votes is not going to suffice for that. |
Beta Was this translation helpful? Give feedback.
-
Dropping support for pre-21 would simplify some virtual thread handling. Other than that, I don't think there are big advantages. Migration from 17 to 21 seems to be relatively painless for users, so there is less reason to stay on 17. Unless there are other big upsides to 21 than virtual threads, I don't think it is worth forcing users to update, even if it would be painless for them. |
Beta Was this translation helpful? Give feedback.
-
Java 22 support would gain a lot: FFM, scoped values, stream gatherers, and so on. I wish these had landed in Java 21 but no such luck. One other consideration would definitely be JPMS. We are using Micronaut with GraalVM, and GVM has already moved to using the In general it is going to be interesting to see how Netty evolves in the presence of new support like Virtual Threads and FFM. Java 21 would help get everyone there even if Java 22 is a little further out. Obviously, Gradle plugins will still need to run under Java 11 or 17, but that's another story. |
Beta Was this translation helpful? Give feedback.
-
The core committers teams, Unity Foundation + Oracle Labs, had a Micronaut Framework 5 planning meeting last Thursday. We have decided to keep the Java 17 baseline for Micronaut Framework 5. |
Beta Was this translation helpful? Give feedback.
-
Should we set Micronaut Framework 5 Java baseline as Java 21?
see: #10483
25 votes ·
Beta Was this translation helpful? Give feedback.
All reactions