The Road to Quarkus 4: Vision, Roadmap, and Timeline

[cescoffier]

Hello,

As we continue to evolve the Quarkus ecosystem, it is time to look ahead to our next major milestone. We are officially kicking off the planning and development phase for Quarkus 4.

Our goal for Quarkus 4 is to leverage the latest innovations in the Java ecosystem (including Project Leyden and JPMS), double down on AI integration, and streamline the architecture to be even more modular and lightweight.

Below is the proposed schedule and the "Big Ticket" items we are targeting.

The Schedule (Tentative)

Please note: This is a no-commitment schedule. These dates represent our current targets and are subject to change based on development progress and upstream dependencies.

• Sept 2026: Quarkus 4.0 Beta 1 (Feature freeze for breaking changes)
• Oct 2026: Quarkus 4.0 Beta 2
• Nov 2026: Quarkus 4.0 GA
• Jan 2027: Quarkus 4.1 (Feature freeze)
• March 2027: Quarkus 4.x LTS

Key Themes and Features

We are tracking the detailed work in this GitHub Project. Here are the headlines:

Core Architecture & Standards

We are making significant changes to how Quarkus is built and packaged to ensure long-term maintainability and performance.

• New Modular Architecture: A shift toward a JPMS-based architecture (in progress)
• JLink Integration: Utilizing JLink to create minimized container images, reducing footprint and attack surface.
• Extension Structure: A re-structure of extensions with support for a Linter to ensure quality consistency across the ecosystem.
• Java Version: We are targeting Java 25 & 21.
  • Discussion Point: We are potentially considering removing support for Java 17. We want to hear your thoughts on this.
• Jakarta EE: Full alignment with Jakarta 11 (requires Java 21 as base).

Reactive Core & I/O

Building on our reactive roots with the next generation of Vert.x.

• Vert.x 5 & Netty 4.2: Adoption of the latest major versions.
• Unified Eventing: Improved EventBus handling to unify CDI events, Vert.x Events, and internal messaging.
• Virtual Threads: Enhanced handling and integration of Virtual Threads throughout the core.
• HTTP/3: First-class support.

AI & LangChain4J.NEXT

Quarkus has become a go-to framework for Java AI development; Quarkus 4 will push this further.

• Agentic Patterns: Full support for building complex AI agents.
• Context Engineering: Native support for managing context windows and history.
• Evaluation: Built-in tools for evaluating model performance.
• Non-blocking Langchain4J: Deep integration with the reactive core.

4. Native & AOT

• Project Leyden: Support for Leyden AOT optimizations.
• Semeru: Support for shared classes in Semeru runtimes.
• Continued support of GraalVM native images

Developer Experience & Compatibility

• Spring Compatibility: Enhanced support including JDBC Template and migration tools based on OpenRewrite.
• JMS: A "Just Enough JMS" implementation for better legacy integration.
• CLI: A new plugin to ease the re-augmentation process.
• Jackson 3: Upgrade to Jackson 3

⠀
This roadmap is a statement of intent. As always, Quarkus is community-driven.

1. Java 17: How would dropping Java 17 support impact your organization in late 2026?
2. Priorities: Are there items here you think are missing, or items listed that you don't believe should be a priority?

Let's discuss below!

[manofthepeace]

Is jackson 3 part of this?

[cescoffier]

Yes, Jackson 3 is part of this. Thanks for reminding me, I will make sure it's tracked in the working group.

[nderwin]

Does the "Full alignment with Jakarta 11" include passing a TCK, perhaps the Core Profile?

[cescoffier]

No, it's the same as today, we take the "good parts", we may be able to pass the TCKs, but this is not a priority.

[radcortez]

Quarkus does pass the Core Profile TCK.

[nderwin]

That's awesome! I haven't seen any emails on the mailing list about that, though. I would love to see it listed as a compatible implementation along side Helidon (so it's not the only one listed in this genre of Java frameworks).

[gsmet]

What do you envision for 3.x once we start release the 4.x CRs?

BTW, I think they should be Betas, not CRs. CRs are release candidates, two months before the GA, it will definitely not be a candidate for release :)

[cescoffier]

Oh, right, my bad, let me switch to Beta.

Until 4.0 GA, 3.x continue at the same pace, after GA, we need to see how much time we maintain an overlap (probably one year).

[yrodiere]

after GA, we need to see how much time we maintain an overlap (probably one year).

Do I understand correctly that there will still be 3.x LTS versions after 4.0 GA for one year? Meaning two 3.x LTS versions?

[gsmet]

I could see how we could release maintenance releases of last 3.x LTS every 2 months for some time.

But I don't see us having the ability to release feature releases in both 3.x and 4.x. So I hope that's not the plan :)

[maxandersen]

"Java Version Baseline: We are targeting Java 25 & 21." - what does having both Java 25 and 21 as baseline mean? some packages will be 25+ and some 21+?

[cescoffier]

In the case we drop 17, the base Java version will be 21. But, as I said, we need to discuss whether we drop 17 (if we don't base version will be 17).

[rsvoboda]

Is "Maven 4 support" a relevant topic?

[aloubyansky]

It's expected to be working.

[aloubyansky]

#37627

[lostiniceland]

Does supporting Maven 4 mean supporting ModelVersion 4.1?

[ERROR] 1) Failed to determine version for project model
[ERROR]   at io.quarkus.bootstrap.resolver.maven.workspace.ModelUtils.getRawVersion(ModelUtils.java:166)

Furthermore, annotation-processor declaration changes (at least if you dont want deprecation warnings) and the new way to define source-folders (without build-helper-plugin) will probably also have an impact.

[aloubyansky]

@lostiniceland thanks for pointing those out. If you can, please, open specific issues and we'll triage them. Thanks!

[lostiniceland]

#52190

[adampoplawski]

Maybe Kotlin First-class support (mostly referring to 100% coroutines support) is planned?

[lostiniceland]

Havent tested this, but would kotlin-coroutine-reactive not suffice?
https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-reactive/

Some years ago I combined akka-streams with mutiny via the reactive-streams spi and it worked. But this was using a custom stream.
I guess you would like to have suspend functions work out of the box at any place.

[adampoplawski]

I guess you would like to have suspend functions work out of the box at any place.

This part. We have Kotlin with pure Mutiny. We dropped coroutines since there were open topics and clear statement that Quarkus (in v2 v3) is not aiming for "suspend functions out of the box". For some teams dropping coroutines/suspended is probably dealbreaker (we were from Spring+Java+Webflux to Quarkus+Kotlin+Mutiny so easier to ignore coroutines/suspended)

[krickert]

Please kill JDK17. Tear off the band aid, people will be forever keeping it if you don't.

I'd also love it if you double down on the service discovery but allow for dynamic discovery of services in quarkus. Right now you force all services to be an annotation when having that dynamic will allow me to get rid of the dynamic ones I had to make.

Specifically with grpc - a factory that would create client stubs through service discovery...

SomeGrpcStub stub = CoolNewFactory.get("stub-instance-a");
SomeGrpcStub stub2 = CoolNewFactory.get("stub-instance-b");

[cescoffier]

@krickert Dynamic discovery is handled using Stork : https://quarkus.io/guides/stork-reference

[krickert]

I know but is there a way we can just not use The annotation to get the service? I would want to be able to get a new service from stork without the need to use config but to do the whole thing at runtime.

That would be a vert.x request?

[krickert]

@cescoffier I know stork has dynamic discovery - but it's not 100% dynamic. The way it's setup, you need to know it at compile time or start time - there doesn't seem to be a way to get the name of a service as a parameter in a function, for example.. unless I'm missing something. I had to write my own, but really hope I just missed something and that it would be trivial

[cescoffier]

There are ways to do that, by either implementing your own service discovery (you have a single service name, but your service discovery identifies and locates the service instance), or use the stork API directly (in a gRPC interceptor).

@aureamunoz any suggestion?

[krickert]

Yeah that's what I did. I'm just surprised that this isn't a regular feature of any framework (micronaut and spring lack this feature as well). I know most developers know what services they run, but if you do a 100% dynamic discovery, it can't work.

I did create a dynamic-grpc extension, but it's not 100% generic - but very close.

In my case, I made a pluggable grpc framework where service modules all have the same interface. So it's registration driven

[adampoplawski]

Sth we felt is missing, dynamically (I mean without redeploying) disabling reactive messaging reading from queues.

[cescoffier]

not really possible, we compute the "graph" at build time to wire everything.
Let's see what @ozangunalp thinks.

[adampoplawski]

Yes, I had feeling this may be big change :) Just sharing recent user experience since it seems like change for major release.

[ozangunalp]

@adampoplawski
The messaging channel enabled=true/false is a "runtime" property, meaning that you do not need to recompile the Quarkus app to enable/disable a particular channel when starting an application: https://quarkus.io/guides/messaging#enabledisable-channels
It still needs to have a complete graph etc.

But I am sure you know that already.

What I understand from this you'd like to start and stop a messaging channel dynamically at runtime.
This is not possible yet, although I'd like to work on the channel lifecycle for Quarkus 4. As Clement said, the processing graph needs to be calculated during runtime to do this.

That being said, we do have the possibility to "pause" message consume/produce for channels using https://quarkus.io/guides/messaging#pausable-channels. This can be used to temporarily and programmatically pause the channel for maintenance operations, or start an application with some channels paused and resume them later at runtime, without touching the processing graph. Also, for some connectors (I think Kafka is the case), you can tweak the config to postpone the creation of the client at the first resume time.
There are still some quirks with health checks that we need to take care of.
This is, however, done programmatically; I've not thought of a scenario where the dynamic config change can trigger pause/resume.

[adampoplawski]

@ozangunalp Thx for explanation.

Our case is that we read from SQS so for each read we pay money. We are processing on some SQS data not in "ongoing fashion". So we would like to without deployment say mp.messaging.incoming.my-channel.enabled=false to stop integration and when we see somenone dropped new batch on SQS for us we just change mp.messaging.incoming.my-channel.enabled=true in AppConfig/SpringCloud/QuarkusCloudConfig(if will happen) and do not need to pay for reads from SQS, when we know 100% will be empty receives.

[krickert]

@adampoplawski

We may be share the same desire to have a more dynamic subscription system as I'm building one now.

1. Sub-Scaling

Are you trying to solve the problem where you have 100 instances of a service running, but you only want 5 of them to actually 'listen' to a specific SQS/S3 event stream at any given time?

I'm doing this but it meant that I had to make a Lease/Orchestration layer.

2. Runtime Subscriptions

Do your workers know exactly what they are subscribing to when they start, or you're suggesting that they change dynamically at runtime?

The standard @Incoming model is build-time optimized, meaning Quarkus expects to validate the channel and subscription before the application even finishes starting up. But in a dynamic graph, the "target" is a runtime state. We need a way to keep the channel "open" in code but "closed" at the connector level until a layer can handle this. To keep it stateless, you typically need a locking or lease system where a coordinator releases a "need" for a subscription, and available workers compete to grab that lease. Once the lease is obtained, the worker starts "listening."

We might be able to handle this with a new annotation and concept, like @IncomingSubscriptionLease. This would allow the use case to be identified and bridged at startup, while the lifecycle is understood that it's dynamic in nature so it would use a different subsystem

[ge0ffrey]

From our open source java library (Timefold Solver) point of view:

Java 17: How would dropping Java 17 support impact your organization in late 2026?

No problem. We intend to release Timefold Solver 2.0 in March 2026 with a minimum of java 21 already and not support Quarkus 4 in Timefold Solver 1.x.

I think the ecosystem moves a lot faster these days than 10+ years ago, thanks to Dependabot, more streamlined deployments, CI/develops and less Backwards Compatibility breakage.

Priorities: Are there items here you think are missing, or items listed that you don't believe should be a priority?

Not anything missing, but some timing concerns:

We have Jackson integration (timefold-solver-jackson). The Jackson 2 to 3 backwards incompatibility is already causing trouble. (We also support Spring 4). Think compatibility matrix. Think ideas like artifactIds of timefold-solver-jackson3.

This creates some concerns for us:
Can Timefold Solver 2.0 in March 2026 support Jackson 3 and Quarkus 3 (but not Jackson 2)?
When Quarkus 3 releases in March 2027, will it force us to release Timefold Solver 3.0?

Hope that helps :)

[lucamolteni]

Nothing on Hibernate / Panache ?

[cescoffier]

Panache.Next just landed. I don't expect a Panche.Next.Next in Quarkus 4.0 :-) (Stephane deserves a break).

That being said, we will need to see which Hibernate version we want in Quarkus 4 and if it requires Java 21 as base.

[yrodiere]

Panache.Next just landed. I don't expect a Panche.Next.Next in Quarkus 4.0 :-) (Stephane deserves a break).

Panache.Next definitely didn't land, it's experimental and subject to (many) changes. Luca was mentioning it because we might want to finalize it in time for Quarkus 4...

[yrodiere]

Not to deny the huge work Stephane did, of course. If Quarkus 4 is too short of a deadline, so be it; but let this be a conscious choice.

[cescoffier]

I have no problem including Panache.Next in Quarkus 4, on the contrary!

[smsajid]

New Modular Architecture: A shift toward a JPMS-based architecture (in progress)

Is this meant only for the quarkus framework itself? or for applications as well?
Is there any thought on supporting something similar to Spring Modulith and https://serviceweaver.dev/ . Application starts small in a monolith way. then as it grows, it can be broken into microservices or parts of it are extracted into microservices. Can such a programming model be supported?

[dmlloyd]

This is targeting applications first, and Quarkus itself second. It would be separate from a "modulith" concept, though I think any solution in that direction would necessarily have to consider modularity.

[smsajid]

I am interested in the serviceweaver concept (but not to the extent of deploying directly to cloud) and that can be done using java modularity. basically, you design your applications using modules. then the quarkus command can build a jar for each module and automatically build grpc (could be REST as well) binding between modules

[maxandersen]

How about the old challenge of the core being quite tied to Maven / Gradle in lots of its assumptions of build system and file structure? i.e. at the moment jbang support is more hacked in than nicely fitting.

I'm not here suggesting this for jbang only, but also for possibly handling multiple versions of maven/gradle over time, or enable mill, bazel, etc. integration via explicit apis over one off workarounds?

@aloubyansky @dmlloyd ?

[cescoffier]

If time allows why not. Is there already ongoing work? September is coming fast...

[maxandersen]

Its part of/related to @dmlloyd 's efforts of being able to create artifacts and modularization. Good Topic for f2f I would say.

[cescoffier]

Oh so, it's already in, then.

Do we have an issue tracking this that I can add to the working group?