Quarkus 4 Progress Report - July 2026

[cescoffier]

Back in January, we shared our vision and roadmap for Quarkus 4. We're now past the halfway mark toward Beta 1 (September 2026), and it's time for a progress update. You can track the overall status on the Quarkus 4 project board.

An important note first: the main branch of the quarkus repository is now Quarkus 4. Quarkus 3.x development continues on the 3.x branch and will continue to receive releases at its current pace until Quarkus 4.0 GA and beyond.

Timeline

The timeline from the original plan still holds:

• September 2026: Quarkus 4.0 Beta 1 (feature freeze for breaking changes)
• November 2026: Quarkus 4.0 GA

Vert.x 5, Netty 4.2, and I/O improvements

The upgrade to Vert.x 5.1.2 and Netty 4.2 is complete. This was a substantial effort; the core I/O layer has been fully migrated and is functional. That said, several areas of the codebase were migrated with a "make it work first" approach and still use non-idiomatic Vert.x patterns. A cleanup pass is underway to adopt Vert.x 5 APIs properly (ContextLocal, stream handling, etc.). See #51959 for the full scope.

On top of the Vert.x 5 foundation, we've been making progress on I/O capabilities:

• HTTP/3 support has been implemented. It will ship as experimental in the first Quarkus 4 release.
• Native transports: we revamped the experience around native transports and now support native mode for both epoll and io_uring. The PR is approved and pending merge.
• Domain sockets can now be used without requiring native transports.

Context propagation

Context propagation and modeling are a large, cross-cutting effort led by @Ladicek and @jponge. This work touches on how context flows through reactive pipelines, virtual threads, and the Vert.x event loop. It is still in progress and is one of the bigger architectural changes in Quarkus 4.

Observability (OpenTelemetry & Micrometer)

The Vert.x 5 and Netty 4.2 upgrades required significant changes in our OpenTelemetry and Micrometer integrations. An analysis is currently underway (by @brunobat) to assess what we lost in terms of metrics and tags compared to Quarkus 3.x, and to determine how we can reduce the breaking changes before GA.

Jackson 3

Work has started on upgrading to Jackson 3. This is another planned severe breaking change for Quarkus 4. @geoand is leading this effort.

AI and LangChain4j

The AI story in Quarkus 4 is evolving on multiple fronts. On the LangChain4j side, a major non-blocking rewrite is underway. It introduces end-to-end reactive support across the entire stack (models, chat memory, guardrails, tools) that integrates deeply with Quarkus's reactive core and virtual thread model. On the Quarkus side, agentic patterns are being revamped to take full advantage of these new capabilities. Expect more on this front during fall. @dmi3coder, @mariofusco are leading these parts.

Our MCP story is also important, with MCP server 2.0 supporting both stateful and stateless interactions and the adoption of the new MCP Java annotations (@mkouba). The client should follow shortly (@jmartisk).

Hibernate 8

The upgrade to Hibernate 8.0 is still planned for Quarkus 4.

AOT: Leyden and Semeru

Initial support for Project Leyden AOT optimizations and Semeru shared classes landed in Quarkus 3.x. We will continue to improve these capabilities in Quarkus 4, but no major changes are planned at the moment, though this could evolve as upstream projects mature.

Modularity and JLink

The modularity track is progressing nicely under @dmlloyd's leadership. The goal is a JPMS-based architecture that enables JLink to produce minimized container images with a reduced footprint and attack surface. The quarkus-jlink extension (introduced as experimental in Quarkus 3.37) is a first step, and the Quarkus 4 timeline allows us to push this further.

Signal: the new event bus

Signal, the new event bus mechanism led by @mkouba, has already been merged and is available in Quarkus 3 as an experimental feature. It provides a unified eventing model across CDI events, Vert.x events, and internal messaging. In Quarkus 4, it will replace the Vert.x event bus.

Quarkus Data (formerly Panache.Next)

Quarkus Data (read this blog post from @lucamolteni and @FroMage) is the next generation of Panache and is shipping as experimental. It aligns with the Jakarta Data standard and introduces type-safe query support via Hibernate Processor annotations. The plan is to finalize it for Quarkus 4 GA.

Just Enough JMS

"Just Enough JMS" is still on the roadmap. @ozangunalp will pick this up once he finishes the new TableView API, another Quarkus 4 feature.

Java 21 baseline

Raising the minimum Java version to 21 remains on the roadmap. From an engineering standpoint, we'd love to make this happen as soon as possible; it unlocks alignment with Jakarta EE 11 and lets us leverage language and API improvements across the board. We're still discussing the implications for the ecosystem and existing users.

Website: potential move to ROQ

The quarkus.io website may switch to ROQ. Stay tuned, we have a community call in two weeks to discuss this topic (with @holly-cummins and @ia3andy)

We want your feedback!

Quarkus 4 is shaping up to be a major step forward, and we need your input. If you've been tracking the main branch, testing HTTP/3, experimenting with Signal or Quarkus Data, or have opinions on the Java 21 baseline, we want to hear from you.

• What's working well?
• What broke when you tried it?
• What's missing from the plan?

Drop your feedback in this discussion, file issues, or join the community call. The Beta 1 feature freeze is in September; now is the time to shape Quarkus 4.

PS: There is a lot more going on in Quarkus 4 - this is just the tip of the iceberg.

[vsevel]

great job :-)
what is the status on graceful shutdown?

[mkouba]

@dmlloyd is working on a new Service start/stop infrastructure. This could be the foundation for the new graceful shutdown stuff. There's another pull request open to use JFR events to trace the shutdown sequence.

[vsevel]

funny I did not see it there: #52020
but it was mentionned in the community calls

Quarkus 4 & Vert.x 5 Roadmap: Significant technical milestones confirmed including Jackson 3 adoption, a Unified Event Model, and graceful shutdown implementation.

it was not clear if this was still a goal. thanks for the clarification.

[vsevel]

Extension Structure: A re-structure of extensions with support for a Linter to ensure quality consistency across the ecosystem.

is this still a goal for quarkus 4 as mentioned in #52020
if so, what is the status, and what effort would that require for extension contibutors?

[cescoffier]

It will be a recommendation following the ADR about the extension structure.
We will be working on a linter to verify if your extension follows the recommended structure.

And yes, still a goal, not for the first beta, most probably the second.

[hamburml]

I would love to see progression in the serverless features like funqy or aws lambda rest/http dependencies for quarkus 4 - they still have the preview flag.

[cescoffier]

Unfortunately, we don't have someone actively working on these, but contributions are more than welcome.

[vsevel]

when is targeted the first beta in september? beginning, mid or late in the month?

[cescoffier]

@gsmet what's your preference?

[WernerderChamp]

I think moving to Java 21 as a baseline is a fair move. I did some research and a lot of major vendors (e.g. Eclipse Temurin, Oracle and Red Hat) will no longer provide free support for Java 17 by October 2027, so anyone not willing to pay will have to move to Java 21/25 anyway.

To me, the way to reduce impact on the ecosystem is to give sufficient time to migrate. To archive this, the last minor on Quarkus 3 should definitly become an LTS version. Backporting fixes might not always be possible, but security fixes and dependency bumps would still need to happen. I think the usual year should be sufficient for this, but a "only security and severe bugs will be fixed"-period might be worth considering.

[gsmet]

To me, the way to reduce impact on the ecosystem is to give sufficient time to migrate. To archive this, the last minor on Quarkus 3 should definitly become an LTS version. Backporting fixes might not always be possible, but security fixes and dependency bumps would still need to happen. I think the usual year should be sufficient for this, but a "only security and severe bugs will be fixed"-period might be worth considering.

That's the plan. The last feature release for 3.x will be 3.40 LTS planned for September.

[vsevel]

the new TableView API

what is it?