Quarkus 4 beta turns a framework upgrade into a platform migration
The first beta moves the Java baseline, networking stack, serialization layer and persistence defaults at once, making early testing more than a compatibility exercise.
Quarkus has published the first beta of its next major release and is asking extension maintainers and application teams to test before a final release planned for the end of November. The release announcement is short; the accompanying migration guide shows why this is not a routine version bump.
What changed
Quarkus 4 raises the minimum runtime to Java 21, recommends Java 25 and drops Java 17 support. Its default container base moves to UBI 10. At the framework layer, the beta combines Netty 4.2 and Vert.x 5 with opt-in HTTP/3, QUIC support, native transports including epoll and io_uring, and a built-in observability dashboard in Dev UI. The release also moves to Jakarta REST 4, Hibernate ORM 8, Jakarta Persistence 4, Jackson 3 and CDI 5, according to the project announcement.
Those upgrades create application-facing changes. The migration guide says Jackson core and databind packages move from com.fasterxml.jackson to tools.jackson, while several deserialization defaults become stricter. The separate gRPC server is removed: gRPC services now share the main Vert.x HTTP server, and clients relying on the old default port 9000 must be redirected. Quarkus also removes a long list of previously deprecated configuration properties and artifact relocations.
Persistence deserves its own test pass. Quarkus now assumes newer database versions at build time—PostgreSQL 16, MySQL 8.4, MariaDB 11.4, Oracle 23, SQL Server 2022 and Db2 12.1 are among the new defaults. The guide warns that applications connected to older databases can fail at startup unless teams upgrade the database or explicitly set a compatible target version. Hibernate ORM 8 also brings stricter query typing, API removals and changes to generated DDL behavior.
Who should act
Extension maintainers have the shortest runway because their work can block application migrations. Quarkus explicitly asks them to port extensions during the beta. Application teams should treat the beta as a compatibility rehearsal across build images, Java runtimes, REST and gRPC endpoints, JSON handling, database targets, observability and security configuration.
What to do now
The project recommends starting with quarkus update; migration items marked in the guide are handled automatically by that tool. Automation does not cover every change, so teams should then run integration tests against real databases and external clients, inspect warnings for unused configuration, compare generated schemas and telemetry, and test container builds on UBI 10. With the final release planned for late November, the beta is the point to discover ecosystem gaps rather than the point to schedule production adoption.
sources
- Quarkus 4.0.0.Beta1 releasedquarkus.io
- Quarkus 4.0 migration guidegithub.com
comments · 0