Quarkus 4 enters beta and puts extension migration on the clock

Quarkus has published the first beta of its next major release, giving application and extension teams an early integration point for a stack-wide upgrade rather than another incremental 3.x update. Quarkus 4.0.0.Beta1 changes the baseline to Java 21 and introduces new major versions across the networking, persistence and serialization layers.

What changed

The beta moves Quarkus onto Netty 4.2 and Vert.x 5.x, with opt-in HTTP/3 support and automatic certificate generation for development and test modes. Native transport support extends to epoll and io_uring, including native executables.

The framework also adds an observation API for generating metrics and traces through Micrometer or OpenTelemetry, plus an out-of-the-box observability section in the development UI. The application stack advances to Jakarta REST 4, Hibernate ORM 8, Jakarta Persistence 4.0, Jakarta Data 1.1, Jackson 3 and CDI 5.0.

Messaging changes include a dedicated JMS extension with Spring JMS, pooled JMS and IronJacamar compatibility, alongside an @ExactlyOnce mechanism for Kafka transactions.

Who should care

Extension maintainers have the most immediate work. Quarkus says the migration guide is denser than its usual minor-release documentation and explicitly asks maintainers to begin porting now. Application teams should use the beta to expose compatibility breaks in dependencies and internal extensions while there is still time to report them upstream.

The Java 21 floor is also a planning boundary for teams carrying older runtime assumptions. Meanwhile, the combination of HTTP/3, QUIC-oriented networking, refreshed persistence APIs and Jackson 3 means testing should cover protocol behavior and serialization as well as compilation.

What to do

Quarkus plans the final release for the end of November. Teams evaluating the beta should first inventory extensions and confirm their Quarkus 4 status, then run representative integration tests against the new Java, networking, persistence and JSON layers. Extension authors should work through the project’s linked migration guide and report failures before the release candidate stage.

This is a beta, not a production recommendation. Its value is that it makes the migration surface concrete early enough for maintainers and platform teams to influence the final release instead of discovering incompatibilities after general availability.