Quarkus 4 rebuilds its I/O core on Vert.x 5.1.2 and Netty 4.2 for a November GA

Project Leyden lets the JVM record class loading and linking while an application runs, then reuse that AOT cache on later startups, and Quarkus wired it in at 3.32 ^[7]. The minimal REST app's 370 ms to 80 ms is a 290 ms saving, about 4.6 times faster ^[19]. The 9,000-class CRUD app saves 2.1 seconds, about 3.3 times ^[20]. The bigger application gets the smaller multiple and the much larger absolute saving. For either number to mean anything on your service, the training run has to exercise the startup paths production takes, and your class count has to sit somewhere near the 9,000 in the test app ^[8].

Both figures are from a plain JVM, so none of the GraalVM native-image costs around reflection configuration, build times and peak throughput apply ^[10]. The dev.to comparison quotes them from the Quarkus 3.32 release post and does not say what hardware or JVM build produced them ^[23]. The same post is blunt about who should care: aggressive pod scaling or serverless makes Quarkus the stronger pick, and if you start the app twice a day in development the startup section matters far less than you think ^[24].

Spring Boot 4.1 attacks startup differently. Lazy JDBC connections keep the datasource uninitialised until first use, and the new spring.jpa.bootstrap property moves JPA bootstrap to a background thread for applications with large JPA models ^[11]. Because both frameworks are converging on the same OpenJDK machinery, the post expects the plain-JVM startup gap to keep shrinking ^[14].

The November collision is real, and the two releases are not the same size of decision. Spring Boot 4.2 is the second minor on a 4.x line that already absorbed its breaking changes in 4.0, including the Jakarta EE 11 baseline and the Jackson 3 move ^[13]. Quarkus 4 is the major, and Quarkus has been flagging Jackson 3 as a severe breaking change well ahead of Beta 1 ^[13]. Signal, the new event bus, is already usable in Quarkus 3 as an experimental feature, and Leyden support landed in 3.x, so what 4.0 carries is mostly the work that could not ship incrementally: the I/O layer on Vert.x 5.1.2 and Netty 4.2, plus HTTP/3 as an experimental feature in the first release ^[15][5][6].

Community maintenance on 3.40 LTS ends in September 2027 ^[4]. It is roughly ten months after Quarkus 4 GA ^[21].

"I have not migrated anything to Quarkus 4. Nobody has, outside the Quarkus team, because Beta 1 is not out yet," the author of the comparison wrote ^[17]. The whole breakdown is drawn from the July 2026 Quarkus 4 progress report, the Quarkus 3.32 release post, and the Spring Boot 4.0 and 4.1 release documentation ^[18].

In my view the ordering is straightforward for a team on Quarkus 3: take 3.40 LTS in September, do the Jackson 3 migration on a version you can still run in production, and treat Beta 1 as a compile-and-test exercise. I would then measure the JLink output against the current container image at GA, because the JPMS work in Quarkus 4 is aimed at smaller images and a reduced attack surface ^[16].