Quarkus

Quarkus 3.34.2 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Thu, 02 Apr 2026 00:00:00 +0000

Today, we released Quarkus 3.34.2, the first maintenance release for our 3.34 stream (we skipped 3.34.0).

Update

To update to Quarkus 3.34, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.34.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.34 migration guide.

完全な変更履歴

You can get the full changelog of 3.34.2 on GitHub.

参加のお誘い

私達は皆様からのフィードバックに重きを置いています。バグ報告、改善要望を是非お願いします。一緒に素晴らしいものを作り上げていきましょう!

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.34 - Enhancements all around

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 25 Mar 2026 00:00:00 +0000

Today, we released both Quarkus 3.33 LTS and Quarkus 3.34.

While Quarkus 3.33 is a Long Term Support (LTS) release, branched from Quarkus 3.32 and maintained for 12 months, Quarkus 3.34 comes with a lot of enhancements across the board: Dev UI, Panache Next, and a lot of other areas got improved.

This release also includes internal changes and refactorings that will bear fruits in future versions.

Update

To update to Quarkus 3.34, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.34.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.34 migration guide.

完全な変更履歴

You can get the full changelog of 3.34.0.CR1, 3.34.0, and 3.34.1 on GitHub.

コントリビューター

The Quarkus community is growing and has now 1173 contributors. Many many thanks to each and everyone of them.

In particular for the 3.34 release, thanks to Ales Justin, Alexey Loubyansky, Andy Damevin, Asger Askov Blekinge, Ashish Thakur, Aurea Munoz, Aurélien Pupier, Bruno Baptista, Carles Arnal, Char, Chris Ruffalo, Clement Escoffier, Clément de Tastes, Daniel Vergien, David M. Lloyd, Dennis Kniep, Dmitri Bourlatchkov, Erwin Oegema, Faisal Dilawar, Foivos Zakkak, Frank Eichfelder, g, Gaelle Fournier, Galder Zamarreño, George Gastaldi, Georgios Andrianakis, Guillaume Smet, Holly Cummins, Inaki Villar, Jakub Jedlicka, Jan Martiska, jcarranzan, JeffersonSantos29, Jens Teglhus Møller, Julien Ponge, Katia Aresti, Kristian Rickert, Ladislav Thon, Luca Molteni, Martin Kouba, Martin Panzer, María Arias de Reyna Domínguez, Matej Novotny, Matheus Andre, Matheus André, Michael Edgar, Michal Maléř, Michal Vavřík, Nico Hinrichs, Ozan Gunalp, Patrick Schaub, Peter Levart, Phillip Krüger, Roberto Cortez, Sanne Grinovero, Sergey Beryozkin, shjones, Stéphane Épardaud, Thomas McWork, tiwari91, Tom Jenkinson, Tom Schindl, Vincent Sevel, xstefank, and Yoann Rodière.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.33 LTS - new LTS version

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 25 Mar 2026 00:00:00 +0000

It is our pleasure to announce the release of Quarkus 3.33, which is our new LTS (Long Term Support) version.

This version is built on the top of Quarkus 3.32. New features landed in Quarkus 3.34, which was also released today.

If you want to know more about our LTS policy, the LTS announcement is a must read.

LTS releases are supported for 12 months.

If you are coming from the previous LTS, Quarkus 3.27 LTS, there are a lot of exciting new features and we recommend reading the following announcements:

Update

To update to Quarkus 3.33 LTS, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.33 LTS.

If you are upgrading from 3.32, there’s nothing to do as 3.33 LTS is the direct continuation of 3.32.

If you are upgrading from the previous LTS, Quarkus 3.27 LTS, please refer to the following migration guides:

Migration guide for 3.28
Migration guide for 3.29
Migration guide for 3.30
Migration guide for 3.31
Migration guide for 3.32
Migration guide for 3.33 - this one is empty as 3.33 is the continuation of 3.32

Note that quarkus update should handle most of the heavy lifting for you, but there are still cases that should be handled manually and we recommend reading these migration guides carefully.

変更点

Platform component upgrades

Various Platform components were upgraded including:

Quarkus CXF to 3.33.0 - see release notes
Camel Quarkus to 3.33.0
Quarkus Operator SDK to 7.7.3
Quarkus Vault to 4.7.0
Quarkus Qpid JMS to 2.12.0

完全な変更履歴

The core part of Quarkus 3.33 LTS is based on Quarkus 3.32 with some additional fixes included in 3.33.1.

You can get the full changelog of 3.33.1 on GitHub.

コントリビューター

The Quarkus community is growing and has now 1173 contributors. Many many thanks to each and everyone of them.

In particular for the 3.33 release, thanks to Ales Justin, Alexey Loubyansky, Andy Damevin, Asger Askov Blekinge, Aurea Munoz, Aurélien Pupier, brunobat, Clement Escoffier, Clément de Tastes, David M. Lloyd, Dmitri Bourlatchkov, Erwin Oegema, Faisal Dilawar, Foivos Zakkak, Gaelle Fournier, George Gastaldi, Georgios Andrianakis, Guillaume Smet, Holly Cummins, Jakub Jedlicka, jcarranzan, Jens Teglhus Møller, Julien Ponge, Katia Aresti, Kristian Rickert, Ladislav Thon, Luca Molteni, Martin Kouba, Martin Panzer, María Arias de Reyna Domínguez, Matej Novotny, Michal Maléř, Michal Vavřík, Nico Hinrichs, Ozan Gunalp, Patrick Schaub, Phillip Kruger, Roberto Cortez, Sanne Grinovero, Sergey Beryozkin, shjones, Stéphane Épardaud, Thomas McWork, tiwari91, Tom Schindl, and Yoann Rodière.

The list is a bit smaller than usual as 3.33 LTS only contains bugfixes on top of 3.32.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.27.3 released - LTS maintenance release

Jan Martiška (https://twitter.com/janmartiska) — Wed, 25 Mar 2026 00:00:00 +0000

Today, we released Quarkus 3.27.3, our next maintenance release for the 3.27 LTS stream.

This release contains bugfixes, documentation updates and fixes the following CVEs:

It should be a safe upgrade for anyone already using 3.27.

Update

To update to Quarkus 3.27, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update --stream=3.27

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.27.

完全な変更履歴

You can get the full changelog of 3.27.3 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.20.6 released - LTS maintenance release

Jan Martiška (https://twitter.com/janmartiska) — Wed, 25 Mar 2026 00:00:00 +0000

Today, we released Quarkus 3.20.6, our next maintenance release for the 3.20 LTS stream.

This release contains bugfixes, documentation updates and fixes the following CVEs:

It should be a safe upgrade for anyone already using 3.20.

Update

To update to Quarkus 3.20, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update --stream=3.20

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.20.

完全な変更履歴

You can get the full changelog of 3.20.6 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Apache Polaris is powered by Quarkus

Tue, 24 Mar 2026 00:00:00 +0000

Apache Polaris, an open-source catalog for Apache Iceberg has officially graduated to become a Top-Level Project (TLP), capping its incubation with a pivotal technical decision: adopting Quarkus as its cloud-native foundation. The fusion of an Iceberg catalog with Supersonic Subatomic Java delivers not only cloud-native efficiency and extensibility but also community collaboration, positioning Polaris as the leading solution for multi-engine data lakehouse architectures.

The Journey to Top-Level Project

Apache Polaris has achieved a major milestone: graduating from the Apache Incubator to become a new Top-Level Project (TLP) within the Apache Software Foundation (ASF). This graduation signifies not only the maturity and community adoption of the project but also its successful integration into the Apache Way of governance and operation.

Understanding the Apache Incubator

The Apache Incubator is the entry point for projects, known as "podlings," seeking to join the ASF. It guides them through the adoption of meritocratic, consensus-based governance, with experienced mentors acting as liaisons between the podling and the foundation’s teams. Polaris successfully completed this mentored incubation process, demonstrating both community maturity and operational readiness.

Technical Evolution During Incubation

For Polaris, the incubation period was not merely an exercise in governance; it also spurred significant technical development and strategic pivots. The project demonstrated its adaptability and commitment to robust architecture by implementing several important changes, including:

A New JDBC Persistence Layer: Enhancing the reliability and flexibility of catalog metadata storage and configuration management.
Advanced Security Features: Integrating new security capabilities, notably through the implementation of the Open Policy Agent (OPA) for policy-based catalog access control, and a sophisticated authorizer framework.
Robust Policy Management: Developing comprehensive frameworks for defining and enforcing catalog access policies and permissions, a core capability for multi-tenant catalog deployments.

Crucially, the team recognized that a successful TLP required a future-proof technical core, which led to one of its most pivotal architectural decisions: adopting Quarkus.

Quarkus Adoption

Among these technical advancements, one of the most pivotal and forward-looking decisions made during the incubation phase was the adoption of Quarkus to power Apache Polaris. This strategic shift recognized that a modern Iceberg catalog serving multiple query engines requires more than traditional Java frameworks could efficiently deliver. The team needed a technology stack that could meet the demanding requirements of cloud-native deployments while maintaining the developer productivity essential for rapid innovation.

Quarkus represents a fundamental shift in how Java applications are built for modern cloud environments. For Apache Polaris, an Iceberg catalog designed to serve multiple query engines, Quarkus provides the ideal combination of performance, developer productivity, and architectural flexibility.

Container-First Architecture

Quarkus was designed from the ground up with a container-first philosophy. Unlike traditional frameworks that were retrofitted for containers, Quarkus optimizes applications specifically for containerized environments by shifting heavy computational work, such as classpath scanning, configuration loading, and dependency injection, from runtime to build time.

For Polaris, this means:

Faster Horizontal Scaling: When deploying additional catalog instances to handle traffic spikes, containers start in milliseconds rather than seconds.
Higher Density: Lower memory footprint allows more Polaris instances per node, reducing infrastructure costs.
Efficient Resource Use: Minimal CPU and memory consumption directly lowers operational cloud costs and provides sustainability benefits by reducing resource consumption.

Performance Characteristics

Quarkus delivers performance through four key dimensions:

Fast Startup Times: By performing application initialization work at build time, Quarkus enables Polaris to start rapidly, critical for auto-scaling scenarios where catalog instances must spin up quickly to handle bursts of metadata requests from Spark, Trino, Flink, or other query engines. To give some numbers, canonical Quarkus applications start in 10ms in native mode, in ~100ms using AOT (Leyden), and in 1 to 3s in plain JVM mode.
Reduced Memory Footprint: The reactive core uses a small number of event loops instead of maintaining large thread pools, dramatically reducing memory usage and enabling higher deployment density.
High Throughput: The reactive, non-blocking engine based on Netty and Eclipse Vert.x enables Polaris to efficiently process numerous concurrent catalog operations, minimizing blocking during I/O to metadata stores or object storage. This non-blocking, reactive architecture allows Polaris to handle thousands of concurrent client connections, such as metadata requests from Spark or Trino, without dedicating a thread per request, thus avoiding thread-contention bottlenecks.
Optimized Resource Consumption: The combination of build-time optimization and reactive architecture results in lower CPU requirements, directly reducing cloud costs for organizations running Polaris at scale.

Developer Productivity and Versatility

Quarkus provides a cohesive, full-stack framework with a rich ecosystem of extensions, enabling the Polaris community to focus on catalog features rather than assembling infrastructure plumbing.

Frictionless Development Experience: The live coding feature provides instant feedback during development, dramatically accelerating the inner development loop and enabling faster iteration on catalog capabilities and security enhancements.

Programming Model Flexibility: Quarkus supports three execution approaches: plain imperative code, reactive programming using the Mutiny API, and virtual threads (JDK 21+), allowing developers to choose the right model for each component. This versatility means Polaris developers can use familiar imperative patterns for simple management endpoints (such as health checks) while fully leveraging the reactive/non-blocking approach (with Mutiny or virtual threads) for high-concurrency, I/O-intensive catalog operations (such as metadata lookups and commits).

Protocol Diversity: Native support for REST, gRPC, GraphQL, and message brokers (Kafka, RabbitMQ, Pulsar, Apache ActiveMQ) gives Polaris flexibility in how it exposes catalog APIs and integrates with the broader data ecosystem.

The Power of the Quarkiverse Ecosystem

Beyond the core framework, Quarkus offers access to the Quarkiverse, an ecosystem of hundreds of community-driven and vendor-supported extensions. Rather than building custom integrations, the Polaris team leverages battle-tested extensions for persistence (PostgreSQL, MongoDB), security (OIDC, OPA), and observability (OpenTelemetry, Micrometer), as the next section illustrates with concrete examples from the codebase.

How Polaris Leverages Quarkus

The true power of the Quarkus foundation becomes evident when examining how Apache Polaris leverages specific Quarkus features in its implementation. The catalog service integrates over 15 specialized extensions to deliver a production-ready, cloud-native Iceberg catalog. Here are a few examples of integration.

Reactive Request Processing with Quarkus REST

Polaris implements the Iceberg REST API using Quarkus REST, leveraging the Quarkus Reactive Core and SmallRye Mutiny to process thousands of concurrent metadata requests asynchronously without blocking threads.

Here’s the actual realm context resolver from the Polaris codebase:

@ServerRequestFilter(preMatching = true)
public Uni<Response> resolveRealmContext(ContainerRequestContext rc) {
   return realmContextResolver.resolveRealmContext(
                   rc.getUriInfo().getRequestUri().toString(),
                   rc.getMethod(),
                   rc.getUriInfo().getPath(),
                   rc.getHeaders()::getFirst)
           .invoke(realmContext -> realmContextHolder.set(realmContext))
           .invoke(realmContext -> ContextLocals.put(REALM_CONTEXT_KEY, realmContext));
}

With just a few lines of reactive code, Polaris achieves multi-tenant request routing that would typically require significantly more boilerplate in traditional frameworks.

Resilience with SmallRye Fault Tolerance

For critical operations such as persisting catalog events, Polaris uses Quarkus Fault Tolerance (which relies on SmallRye Fault Tolerance) to ensure reliability. Here is an example of how Polaris implements a resilient flush operation to the metadata store:

@Retry(maxRetries = 5, delay = 1000, jitter = 100)
@Fallback(fallbackMethod = "onFlushError")
protected void flush(String realmId, List<PolarisEvent> events) {
   var metaStoreManager =
        metaStoreManagerFactory.getOrCreateMetaStoreManager(realmContext);
   metaStoreManager.writeEvents(callContext, events);
}

This declarative approach to resilience means Polaris automatically retries failed writes to the metadata store, with configurable backoff and jitter to prevent thundering herd problems. Note that all the configured values can be overridden in the application configuration.

Using CDI beans as extension points: selecting the persistence layer

Polaris supports multiple persistence backends (PostgreSQL via the Quarkus JDBC PostgreSQL extension, MongoDB via the Quarkus MongoDB Client extension, and in-memory for testing) using Quarkus’s CDI qualifier mechanism:

@Produces
@ApplicationScoped
Backend backend(BackendConfiguration config, @Any Instance<BackendBuilder> builders) {
   var backendName = config.backend()
           .orElseThrow(() -> new IllegalStateException(
               "Configuration polaris.persistence.nosql.backend is missing!")
           );
   var builder = builders.select(BackendType.Literal.of(backendName));
   return builder.get().buildBackend();
}

This architecture allows operators to deploy Polaris with the persistence layer that matches their infrastructure requirements, simply by changing the polaris.persistence.nosql.backend configuration property.

Comprehensive Observability

Polaris leverages Quarkus Micrometer with Prometheus registry and Quarkus OpenTelemetry for complete observability. The catalog automatically tracks:

HTTP metrics for all Iceberg REST API requests, tagged by realm, operation, and status code
Custom gauges and counters for catalog-specific metrics like table count, namespace count, and metadata operation latency
Distributed traces that follow requests across catalog operations, from initial metadata request through to storage access

The metrics endpoint is exposed on a separate management port (8182), isolated from the main API port (8181), following Kubernetes best practices:

quarkus.http.port=8181
quarkus.management.enabled=true
quarkus.management.port=8182
quarkus.micrometer.enabled=true
quarkus.micrometer.export.prometheus.enabled=true

Collaboration between Quarkus and Polaris Communities

The adoption of Quarkus has created a productive feedback loop between the two communities. Engineers from both projects have worked closely together to ensure Quarkus is used effectively within Polaris, reporting bugs and identifying possible enhancements along the way. This hands-on collaboration benefits both sides: Polaris gets a solid, well-understood foundation, while Quarkus gains real-world feedback from a demanding, high-throughput Apache TLP deployment, driving stability and performance improvements that benefit the entire Quarkus ecosystem.

Looking Ahead

The successful graduation of Apache Polaris as a Top-Level Project, combined with the power and efficiency gained from its foundation on Quarkus, is merely the launchpad for a significant, forward-looking technical agenda. Polaris is positioned not just for growth, but to actively shape the future of cloud-native data lakehouse architectures.

The community is already aligning its development with the cutting edge of the Quarkus roadmap, including the forthcoming Quarkus 4 major release. This alignment guarantees that Polaris will continually benefit from performance gains, new cloud-native APIs, and the most advanced capabilities for its reactive core.

Our vision extends to embracing new networking and security standards to meet the demands of the most critical deployments:

Next-Generation Networking: We are exploring the adoption of HTTP/3, leveraging its multiplexing and reduced head-of-line blocking to further minimize latency and boost the throughput of metadata requests, which is crucial for query engines managing thousands of concurrent operations.
Future-Proof Security: Looking beyond today’s standards, the project is investigating quantum-safe TLS and encryption. By integrating modern cryptographic practices, Polaris aims to provide a catalog that is secure not just for the present, but against the computational challenges of the future.

This commitment to continuous innovation, driven by an active community, ensures that Apache Polaris is ready to become the industry standard for high-performance, secure, and multi-engine Iceberg catalog interoperability. We welcome contributors, users, and organizations to join us in defining this next era of the data ecosystem.

Quarkus Newsletter #66 - March

James Cobb (https://twitter.com/insectengine) — Thu, 19 Mar 2026 00:00:00 +0000

In order to provide a transparent and comprehensive performance picture, Quarkus rebuilt its benchmark. Learn more in "Quarkus has great performance – and we have new evidence" by Holly Cummins. Read "How Project Leyden brought a new perspective" by Guillaume Smet to see how Project Leyden gave us a new perspective on how we think about startup performance in Quarkus. Check out Juarez Junior’s post "Unleash the Power of AI Agents with Java: Building Intelligent Applications with Quarkus, LangChain4j, and Oracle AI Database" to learn how to build a Quarkus-based AI support agent that handles customer support for Oracle database error codes. See how executable architecture tests with Taikai replace diagrams, reviews, and tribal knowledge in modern Java systems in "Your Java Architecture Is Lying to You: Enforcing Real Boundaries with Quarkus" by Markus Eisele. Nowadays, Java enterprise applications often default to Angular, React, or Vue for the frontend. But for this kind of applications, the most natural UI framework already exists in the Java ecosystem: Jakarta Faces. Learn more in "Rethinking Java Web UIs with Jakarta Faces and Quarkus" by Nicolas Duminil. See how Markus Eisele built a streaming ingestion pipeline with SSE, batching, and PostgreSQL to track Java-related conversations in "Listening to the Fediverse with Java: A Real-Time Quarkus Experiment". Read "DPoP: What It Is, How It Works, and Why Bearer Tokens Aren’t Enough" by Hüseyin Akdoğan to learn what DPoP (Demonstration of Proof-of-Possession) is, what problem it solves, and walk through a working implementation with Keycloak and Quarkus.

You will also see the latest Quarkus Insights episodes, top tweets/discussions and upcoming Quarkus attended events.

Check out Newsletter #66: March!

ニュースレターを受信してみませんか？ページ上のフォームを使ってニュースレターに登録してください。

Quarkus 3.32.3 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 11 Mar 2026 00:00:00 +0000

Today, we released Quarkus 3.32.3, the second maintenance release for our 3.32 stream (we skipped 3.32.0).

We encourage you to test it, even if you track LTS releases, as 3.32 will be the foundation for 3.33 LTS.

Update

To update to Quarkus 3.32, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.32.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.32 migration guide.

完全な変更履歴

You can get the full changelog of 3.32.3 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.32.2 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Thu, 05 Mar 2026 00:00:00 +0000

Today, we released Quarkus 3.32.2, the first maintenance release for our 3.32 stream (we skipped 3.32.0).

We encourage you to test it, even if you track LTS releases, as 3.32 will be the foundation for 3.33 LTS.

Update

To update to Quarkus 3.32, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.32.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.32 migration guide.

完全な変更履歴

You can get the full changelog of 3.32.2 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

How we integrated Project Leyden into Quarkus

Thu, 05 Mar 2026 00:00:00 +0000

Quarkus has long supported both JVM and native image modes, each optimized for different trade-offs. Native image delivers unmatched startup and footprint. JVM mode offers peak throughput, dynamic capabilities, and a mature tooling ecosystem.

Quarkus continues to improve and work well with native-image, and lately Project Leyden enabled us to strengthen the JVM side of that equation.

We shared our excitement about Project Leyden and how it gave us a new perspective on Java application startup performance in a previous blog post.

In this post, we want to share our journey integrating Project Leyden into Quarkus, and how we made this integration both efficient and easy to use for our users.

Acknowledgements

First, we would like to thank the OpenJDK team at IBM for their work on Project Leyden and for the many discussions we had with them, which were instrumental in helping us understand Leyden and determine how best to integrate it into Quarkus, namely (in alphabetical order), Maria Arias de Reyna Dominguez, Andrew Dinn, and Ashutosh Mehra.

More broadly, we would like to thank everyone contributing to Project Leyden.

Project Leyden is still evolving, and we look forward to seeing what they are preparing for Java 27 and beyond.

Finally, special thanks to Sanne Grinovero for introducing us to the Leyden team at just the right time, and for his insights and valuable feedback on our work.

What is Project Leyden?

GraalVM and the popularization of AOT in Java

In the Java world, Ahead-of-Time (AOT) compilation rose to prominence with the introduction of GraalVM native image, which compiles Java applications into native executables.

It made a huge impact on the Java ecosystem and was a game changer for Java application startup performance:

Startup time and memory footprint are significantly reduced.
There is no warmup phase, as the code is already compiled to native code. Performance is effectively at its peak from the start.
The resulting executable is small, leading to much smaller container images.
The Resident Set Size (RSS) memory usage is much smaller compared to a regular JVM application.

But this comes with some drawbacks:

Not all Java features and libraries are supported out of the box as they are on OpenJDK.
It relies on a closed-world assumption and removes most runtime dynamism (at least in its current form - work on the GraalVM side could change this in the future). Note: This was not and is not an issue for Quarkus as it makes the same assumption; it can be problematic for third-party libraries.
It introduces specific constraints, the most common being the need to provide explicit reflection configuration. These requirements add effort during development and testing, although they are minimized for Quarkus supported extensions.
Native image builds are significantly slower. This typically does not affect the inner development loop (except when debugging native-specific issues), but it can have a noticeable impact on CI resources.
Debugging native executables is hard. It has improved, but it is still a lot harder than debugging in the JVM as it requires the use of GDB and the presence of debug symbols in the build.
And since everything is AOT-compiled, there is no JIT compiler to optimize code at runtime, which can lead to suboptimal peak performance in some cases.

All in all, native image is an excellent option when startup time and footprint are the primary goals.

However, not all applications optimize for those dimensions. Some prioritize peak throughput, development velocity, debuggability, and compatibility with existing tooling. This is where Leyden becomes interesting, aiming to improve startup and footprint while staying closer to the traditional JVM model.

Project Leyden’s approach to AOT

Project Leyden addresses the same fundamental problem as GraalVM native image, but takes a different approach:

It is still "pure" Java, it is part of OpenJDK: your application runs on the JVM, with full access to Java features and libraries, without special configuration.
During a training phase, it records application behavior and gathers information such as loaded and linked classes, and in more recent versions also starts recording some JIT output - increasing scope and optimization potentials in each JVM version.
This information is stored in an AOT cache file.
At startup, you configure the JVM with this AOT cache file.
Because the application still runs on the JVM, you continue to benefit from the JIT compiler, your preferred garbage collector, and all other JVM optimizations, preserving the high throughput typically associated with the JVM.

The AOT cache is exactly that: a cache. If a class is not present in the cache, it is loaded and linked as usual.

Project Leyden reduces startup time by optimizing class loading and linking. It reduces warmup time by providing the JVM with profiling information, and will reduce it even further once compiled code itself is stored in the cache.

Figure 1. How Leyden works

That said, Project Leyden is not magic either. In its current form:

Startup and warmup time improvements are significant, but not as substantial as with GraalVM/Mandrel native image.
You must train your application and generate the AOT cache. In practice, this is not difficult, and in Quarkus, we have made it as seamless as possible.
You still need to ship a JVM with your application.
You also need to ship the AOT cache, which means container images will be significantly larger than with native executables.
You don’t get any memory footprint benefit yet: in most cases, it’s comparable to a regular JVM.

Our take is that Project Leyden offers a compelling balance between performance and compatibility, at a very reasonable cost, and could become part of the default deployment workflow for many Java applications running on the JVM.

Project Leyden status

In OpenJDK 25, the following Project Leyden-related JEPs are available:

Together, these JEPs make Project Leyden fully usable starting with OpenJDK 25.

Additional JEPs are planned for OpenJDK 26 and beyond.

Project Leyden in Quarkus

Quarkus is a highly specialized framework, with extensive build-time processing and optimizations. Project Leyden is a specialized technology as well, with its own constraints and requirements.

Our goal was to integrate Project Leyden into Quarkus in a way that preserves what Quarkus does best, while also maximizing the benefits of Leyden.

Quarkus 3.32 includes the first version of our end-to-end Leyden integration. Let’s take a closer look at how it works.

AOT JAR packaging

You may be used to seeing your Quarkus application packaged in a target/quarkus-app/ directory, but that wasn’t always the case. In the early days of Quarkus, we built a traditional runner JAR in target/, with dependencies placed in a lib/ directory, much like most other Java frameworks.

The current default packaging in Quarkus is called fast-jar. One of its primary goals is to optimize class loading.

We achieved this by introducing our own class loader, which, for example, keeps a package name → jar file mapping in memory. It also includes additional optimizations, such as maintaining a full directory index for specific locations like META-INF/services. These are just a few examples of what this packaging does, but they should give you some context.

This packaging performs very well in the traditional JVM world, but it doesn’t play nicely with Project Leyden.

Project Leyden takes a conservative approach: it only caches classes loaded by the standard JDK class loaders. In other words, no custom class loaders are allowed if you want to fully benefit from AOT caching.

We hope that, at some point, this limitation will be lifted by the Leyden team. If that happens, we will return to the fast-jar packaging, or an evolution of it.

To be precise: you cannot use custom class loaders to load classes if you want to fully benefit from AOT caching. However, you can still use a custom class loader for loading resources only.

This is why we developed a dedicated packaging for Project Leyden: aot-jar. It is automatically selected when AOT is enabled, making the transition completely transparent. It uses the same file layout as the fast-jar packaging.

In addition to delegating all class loading to the JDK class loader, this packaging has a few specific characteristics:

It collects service descriptors from META-INF/services, aggregates them, and keeps them in memory.
It applies the same approach to Quarkus configuration files (e.g., application.properties).
It maintains a full index of specific directories (e.g., the root directory, META-INF, and META-INF/services).
It introduces a pre-initialization phase, during which selected elements are preloaded in parallel (e.g., the time zone database).

As this packaging format is new, we hope to gather feedback from real-world usage.

Let’s be clear: aot-jar performs worse than fast-jar when Project Leyden is not used.

It does not include all the optimizations of fast-jar and is intended to be used only in conjunction with Project Leyden. So it should not be used outside of this specific use case.

Training and AOT cache generation

The AOT cache is only as good as the training data used to generate it. During the training phase, the JVM records which classes are loaded and linked, and collects method profiling data. The more representative the training workload, the more effective the resulting cache.

We wanted training to be as seamless as possible for Quarkus users. The natural fit was to leverage the existing integration test infrastructure: if you already have @QuarkusIntegrationTest tests, they can serve as the training workload.

When AOT training is enabled, the flow is as follows:

Quarkus builds the application with the aot-jar packaging.
The application starts with AOT training enabled.
Integration tests run against the application, exercising its endpoints and features.
The JVM captures profiling data during the entire test execution.
An optimized app.aot cache file is generated from the recorded data.

This is both practical and effective: you already write integration tests to validate your application, and they also happen to produce somewhat realistic training data for the AOT cache.

Integration tests that use @QuarkusIntegrationTest make it very easy to run the target application as they use Dev Services.

Integration with the build system

We wanted enabling Leyden in Quarkus to be a one-flag operation.

Setting quarkus.package.jar.aot.enabled=true is all it takes. Quarkus automatically switches to the aot-jar packaging and sets up the entire AOT pipeline.

With Maven, the full flow is a single command:

./mvnw verify -Dquarkus.package.jar.aot.enabled=true -DskipITs=false

This builds the application, runs integration tests with AOT training, and generates the app.aot cache file in target/quarkus-app/.

If you are using a project generated by our tooling, integration tests are disabled by default. Adding -DskipITs=false makes sure they will be run.

Running the application with the AOT cache is just as straightforward:

cd target/quarkus-app
java -XX:AOTCache=app.aot -jar quarkus-run.jar

We also integrated AOT with the container image extensions (Jib, Docker, and Podman). When building a container image with AOT enabled, Quarkus:

Builds the application with aot-jar packaging.
Creates a base container image.
Runs integration tests against the container to train the AOT cache.
Produces a final container image (with an -aot suffix in its version) that includes the AOT cache and is pre-configured to use it at startup.

This end-to-end integration means going from source code to an AOT-optimized container image in a single command.

Some numbers

We’ve described the benefits of Project Leyden in theory, but how does it perform in practice?

To find out, we collected some numbers for two different Quarkus applications:

A simple REST application, the one you get when you run quarkus create app
A very large REST CRUD application: 1,000 entities, 1,000 repositories, 1,000 services, 1,000 REST endpoints… 9,000 .java files in total. This is an extreme case, don’t try this at home!

The container image sizes were measured using our default images, which are based on Red Hat’s UBI 9 Minimal and use JDK 25.

Raw numbers

These numbers were obtained using a full recording of all classes loaded during startup. They were measured on our laptops rather than in an isolated lab environment. We plan to run a more comprehensive set of benchmarks in our lab soon.

Your results may vary for several reasons:

Not all classes required at startup were recorded.
Your application performs actual work during startup, Leyden only optimizes class loading, not application logic.

In any case, if you see unexpected results, we’re very interested in your feedback. Please reach out to us, and we’ll guide you on how to gather useful profiling information.

RSS is for Resident Set Size memory usage.

Small REST application

Startup time Diff Container image size Diff RSS Diff

	Startup time	Diff	Container image size	Diff	RSS	Diff
Default fast-jar	`370 ms`	`参考`	`456 MB`	`参考`	`122 MB`	`参考`
Project Leyden and aot-jar	`80 ms`	`-78%`	`495 MB`	`+9%`	`103 MB`	`-16%`
Mandrel native executable	`17 ms`	`-95%`	`155 MB`	`-66%`	`37 MB`	`-70%`

Default fast-jar

370 ms

参考

456 MB

参考

122 MB

参考

Project Leyden and aot-jar

80 ms

-78%

495 MB

+9%

103 MB

-16%

Mandrel native executable

17 ms

-95%

155 MB

-66%

37 MB

-70%

The AOT cache file is 39 MB in size, the minimum you can expect for a Quarkus REST application.

Large REST CRUD application

Startup time Diff Container image size Diff RSS Diff

	Startup time	Diff	Container image size	Diff	RSS	Diff
Default fast-jar	`3,189 ms`	`参考`	`517 MB`	`参考`	`580 MB`	`参考`
Project Leyden and aot-jar	`924 ms`	`-71%`	`715 MB`	`+38%`	`580 MB`	`0%`
Mandrel native executable	`242 ms`	`-92%`	`244 MB`	`-53%`	`210 MB`	`-64%`

Default fast-jar

3,189 ms

参考

517 MB

参考

580 MB

参考

Project Leyden and aot-jar

924 ms

-71%

715 MB

+38%

580 MB

0%

Mandrel native executable

242 ms

-92%

244 MB

-53%

210 MB

-64%

The AOT cache file is 198 MB, not surprising, given that the application contains 9,000 .java files.

Startup time

Startup time is greatly improved by Leyden, both for small and very large applications. While it doesn’t quite match the startup speed of a native executable, the results are still impressive.

Let’s pause for a moment. We were able to start a Quarkus REST application in the JVM in just 80 ms.

Figure 2. Quarkus starting fast!

Granted, it’s a simple REST application with a single endpoint, but it still relies on a full-featured REST implementation. And it runs in the JVM.

For very large applications, the results are just as impressive: we were able to reduce startup time by 71%.

Container image size

It won’t come as a surprise: you also need to include the AOT cache file in your container image, so Leyden increases the image size.

For a Quarkus REST application, the minimum is around 40 MB. The cache size grows as your application becomes larger.

On the other hand, going native significantly reduces the container image size, since you no longer need to include the full JVM.

Memory footprint

In terms of RSS, Project Leyden does not significantly change the picture, while native executables offer a substantially lower memory footprint.

Reducing memory usage has not been a primary goal of Project Leyden so far, though this may evolve in the future.

Let’s take a step back

At this point, you might be thinking: "Why not just go native for everything?". For all the reasons we’ve outlined, use native when it makes sense for you.

There’s also the question of throughput. We haven’t collected throughput numbers ourselves, as we didn’t have the proper setup, but some of our colleagues are running tests in an isolated environment, and recently published new benchmark results. Native executables usually result in lower throughput, at least with what is available as Open Source today in Mandrel and GraalVM CE.

This is where Project Leyden really shines: you get significantly faster startup times compared to a regular JVM, while still retaining all the benefits of running on the JVM.

What’s next for Leyden in Quarkus?

Project Leyden is actively evolving, and we are closely tracking its developments, in particular via the premain branch of the OpenJDK Leyden repository, where experimental features are developed before being integrated into mainline JDK releases.

There are several areas where we expect things to improve:

Storage of JIT-compiled code in the AOT cache, which would further reduce warmup time.
Potential support for custom class loaders, which would allow us to return to the more optimized fast-jar packaging.

On the Quarkus side, we are also working on:

Testing and validating on additional platforms, including Windows.

As Project Leyden matures, we will continue to integrate new features into Quarkus. We are looking forward to what Java 27 and beyond will bring.

まとめ

After a month of experimenting and working on the integration of Project Leyden into Quarkus, we are very excited about the results and the potential of this technology. And we are very happy we were able to integrate it into Quarkus 3.32 so that you can play with it already.

Project Leyden is being continuously improved and is likely to figure prominently in the future of the Java platform. As part of our quest in Quarkus to provide the best development platform, with the help of the OpenJDK team at IBM, we are actively monitoring the progress made upstream (in the premain branch of git@github.com:openjdk/leyden.git) and plan to continue shaping the Quarkus + Leyden experience accordingly.

With AOT support, Quarkus expands its runtime flexibility: plain JVM, Leyden-optimized JVM, and native image.

Rather than replacing one another, these modes form a spectrum of trade-offs. Native image remains unmatched for startup and minimal footprint. Leyden strengthens the JVM startup story.

Which works best depends on your priorities, constraints, and application workload.

Our commitment is unchanged: give developers the best option for their workload and keep improving each path.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus has great performance – and we have new evidence

Holly Cummins (https://twitter.com/holly_cummins) — Mon, 02 Mar 2026 00:00:00 +0000

tl;dr

Performance is important to Quarkus, but our published performance graphics were outdated and missing important information (such the fact that we have fantastic throughput). To fix that, we built a new benchmark that is transparent, reproducible, and measures the full performance picture. In our experiments, Quarkus can handle 2.7 times more transactions per second than Spring Boot, as well as starting 2.3 times faster, all in half the memory.

The start of the story

If you’ve ever visited the quarkus.io site (and of course you have, because you’re here), you’ll probably have spotted the performance charts near the bottom of the front page. The Quarkus team are proud of our performance, because good performance means high scalability, low latency, low resource usage, lower costs, and better sustainability. Basically, performance matters. This is what we used to show:

But despite the importance of performance, our performance charts had a few problems. Firstly, the numbers are out of date. How out of date? Well, it’s hard to say, because there’s no date on the chart. In fact, there’s no information at all about how the numbers were measured, and no link to the benchmark source code. This means no one can reproduce it, which means no one can validate. If it’s not reproducible, it’s not trustworthy.

Why didn’t we just link to the benchmark source code? Historically, we’ve been deliberately vague about what we were comparing against (manners!). Sharing the source code would have made it totally obvious what the other framework was. As well as preventing us from the sharing of the benchmark source, anonymizing the other framework had its own problems. Not sharing the framework name is polite, but it means we’re not giving readers useful information to make an informed choice of framework. Is Quarkus better? Oh yes, definitely. Better than what? Shhh, that’s a secret.

But there’s an even bigger problem with our old graphics, in my view. We show Quarkus starts fast, and we show it has a small footprint. We do not show anything about throughput. There’s a classic performance tradeoff between throughput and memory footprint or startup time. It’s easy for people looking at the charts to assume that if Quarkus doesn’t show its throughput figures, they must be terrible, right? Wrong! For Quarkus, there is no trade-off. Quarkus is more efficient than alternatives across the board. (Want to know where trade-off strikes back? Read on.)

But this misconception that Quarkus must have bad throughput turns up all over the place. It keeps popping up in external blogs, and if you ask your favourite AI service about the advantages of Quarkus, it’s unlikely to mention throughput. Instead, it will focus on startup time or memory. Those are important, but so is throughput.

There’s another, more subtle, omission in our charts that also contributes to misunderstanding about Quarkus. We show the performance of Quarkus in native mode, but we don’t show the performance of the other framework in native mode. Some people take this to mean that Quarkus is all about native mode, and if they’re using Quarkus, they should be using native mode. We often see blogs which compare Quarkus in native mode to other frameworks in JVM mode, which is just silly. Quarkus in JVM mode should be compared to other frameworks in JVM mode, and Quarkus in native mode should be compared to other frameworks in native mode. Quarkus happens to be very good at native mode, but whether you want to use native mode is an orthogonal choice to what framework you choose.

Because of all these problems, several members of the Quarkus community have ended up their own benchmarks to use in conference talks, or for demos. I’ve done it myself, in fact. Having members of the same team re-doing similar work is wasteful. What’s more, benchmarking is hard! Getting numbers is trivially easy, but getting numbers which are actually measuring what you think you’re measuring is hard. Doing it really really right needs the sorts of skills performance specialists have.

Ok, so we definitely needed a new benchmark

Something had to be done. Luckily, my colleague Eric Deandrea had been working on this exact problem for several years. Eric had a benchmark, based on an earlier one from John O’Hara, and he’d built up a set of automations which allowed measurements to be run in our performance lab, under controlled conditions.

Eric and I set up a new repository, moved Eric’s benchmark code into there, and refined the automations to push results out past the lab’s firewall to another repository, acting as a data store. We got numbers, and (after a bit of work with Apache Batik), pictures! Notice how great Quarkus’s throughput is. Quarkus can handle 2.7 times (19255 vs 7238 tps) more transactions per second than Spring Boot, as well as starting 2.3 times (2.919s vs 6.569s) faster, all in half the memory (269 MB instead of 583 MB).

This was when the real work began. With the benchmark now open sourced, it was open to scrutiny in a way it hadn’t been before. (This, of course, is part of the magic of open source.) Francesco Nigro, one of our Quarkus performance experts, spotted some areas where measurements could be made more robust. For example, our setup used cgroups with cpuset to pin processes to specific CPU cores — which is the right approach — but both the application under test and the load generator ended up in the same cgroup, competing for those same cores. With the load generator configured to use 16 threads, this introduced significant noise in the measurements. Switching to separate core assignments fixed that, though other sources of interference remained, such as the database not having its own dedicated cores and a cache-drop step that was inadvertently affecting every process on the host. Once proper isolation was in place, the throughput results shifted — and in a subtle way. Before the fix, slower frameworks appeared competitive because their lower load left more breathing room for the other processes. They were being flattered by the very contention they were causing less of. The chart above reflects the improved setup. This is what I meant earlier about benchmarking requiring skill — these mistakes are easy to make and subtle to detect.

But the best help came from outside the Quarkus community. Our intention with the benchmark was to replicate the experience of a normal user, not to tune each framework to within an inch of its life. (There’s TechEmpower for that.) Measuring the "out of the box" performance seemed like the best route, partly because the sort of performance most people will experience by default, and also because it was most fair. Fairness was a strong goal, because otherwise, what’s the point in comparing? Our team have the skills to tune Quarkus applications to razor-sharp performance, but most of us don’t have those same skills for Spring. It’s just not in our job description. Tuning Quarkus but not Spring would clearly not be fair.

But after we’d started publishing the first set of results, we were approached by people who used Spring Boot every day. They pointed out that there were differences in how the two frameworks handled open-session-in-view settings, and connection pool sizes. These differences were significant enough that we started to evaluate whether comparing the out-of-the-box behaviour actually was the fairest option. It turns out that open-session-in-view settings and fixing the N+1 problem didn’t make much difference to the numbers, but adjusting connection pool sizes did. In its default configuration, the Spring application was suffering from serious connection errors. If the client can’t connect, there’s no throughput, so the errors were lowering throughput. Eric, Francesco, and Sanne Grinovero spent a lot of time digging into the logs and profiling to work out configuration tweaks to ensure the Spring application could handle the load without errors.

Our Spring friends told us that these sorts of adjustments would be completely standard. We still wanted to measure out of the box performance, so we settled on a compromise. We measured both out of the box, and a lightly tuned version. In the graphics we show on the front page, we’re showing the tuned version. Here’s the tuned equivalent of the out of the box results above, for the same code level and scripts:

You can see that the effect of the tuning was pretty modest, overall. Notice, as well, that there was a bit of a trade-off between throughput and memory footprint; for both frameworks, the tuning optimisations ended up sacrificing some memory to improve speed.

Guiding principles

In trying to decide how to handle the question of tuning, we ended up referring back to the guiding principles for the whole exercise. They were:

Parity

The application code in the Spring and Quarkus versions of the application should be as equivalent as possible to perform the same function. This means the domain models should be identical, and the underlying persistence mechanisms should be identical (in our case, JPA with Hibernate). Performance differences should come from architecture differences and library-integration optimisations in the frameworks themselves. If a change is made that changes the architecture of an application (i.e. moving blocking to reactive, using virtual threads, etc), then these changes should be applied to all the versions of the applications.

Normal-ness

Realism is more important than squeezing out every last bit of performance.

High quality

Applications should model best practices. Although we want the application to represent a typical usage, someone who copies it shouldn’t ever be copying 'wrong' or bad code.

Testing the framework, not the infrastructure

Measurements should be measuring the performance of the frameworks, rather than supporting infrastructure like the database. In practice this means we want the experimental setup to be CPU-bound.

Exploring our performance

One of the nice things about this work is that it’s allowed us to explore various performance-related questions, beyond just "does Quarkus have awesome performance?" For example, would running with virtual threads affect the results? Yes! Virtual threads added about 6k transactions per second, for all frameworks.

And we had more questions, too. Was there a performance difference between Spring Boot 3 and Spring Boot 4? It turns out things got better in some ways, and worse in others. Spring 4 gives higher throughput than Spring 3, but at the expense of a slower time to first response, and a higher memory footprint.

What would Quarkus' new AOT packaging do for startup times? (We’re still working on that one, but I’m excited to see the answer.)

The throughput vs startup tradeoff, revisited

I mentioned that with Quarkus, there was no trade-off between startup time and performance. When compared to other frameworks, this is definitely true. The internal efficiencies of Quarkus, like the build-time principle, improve both startup time and throughput. But if you compare Quarkus on JVM against Quarkus native, the trade-off is back! When using GraalVM to compile Quarkus applications to native, Quarkus starts faster than a lightbulb, and has a pretty small memory footprint. But there is a throughput penalty. Going native cuts throughput in half. (For Spring Boot, the native penalty is similar.) For most applications, this trade-off isn’t worth it, especially when combined with the longer build times and extra constraints of native. But sometimes, the trade-off is worth it: if your application gets started and stopped super-often or has very low workloads, use native.

Want to try the benchmarks at home?

You can! All of the source code and scripts are available at https://github.com/quarkusio/spring-quarkus-perf-comparison. Easy reproducibility for everyone was an important guiding principle when we designed the benchmark, but it does get kind of complicated. In the performance world, "rigorous" and "easy" do not go in the same sentence. As someone who always wants to make hard things accessible, this really frustrates me. In the end, we’ve ended up with a compromise. If you happen to have a performance lab handy, this is of course ideal. All of the scripts are available for you to run the jobs on your own hardware. If you don’t have that kind of setup, but do have a Linux machine, you can still use the expert-approved scripts we use. Under the covers, they use tools like qDup for orchestration and Hyperfoil to drive load without risking coordinated omission, and ensure process isolation.

But what if you want something really easy? At this point, things get harder. We created a second version of the scripts which are optimised for simplicity. They use only familiar tools, and don’t attempt process isolation. Because of this, they can be run on both Mac and Linux, and, with the right terminal, Windows. The results need to be treated with caution; laptop power management can cause all sorts of wild effects, and if the load is too much or too little, you might end up measuring a bottleneck which has nothing to do with Quarkus or Spring. We’re planning another blog (or six!) on how to avoid the most common problems, and how to tell if you’re measuring what you think you are.

Quarkus 3.32 - Project Leyden integration, more graceful shutdown, automatic Consul registration and more!

Guillaume Smet (https://twitter.com/gsmet_) — Thu, 26 Feb 2026 00:00:00 +0000

We’re pleased to announce the release of Quarkus 3.32.

This is an important milestone: 3.32 marks the feature freeze for our next LTS release, Quarkus 3.33 LTS. The upcoming LTS will be branched from the 3.32 line, making this release the foundation on which 3.33 LTS will be built.

Quarkus 3.32 also delivers several significant improvements and new features:

#52376 and #52224 - Project Leyden integration
#50975 - Rework graceful shutdown to be more graceful with respect to HTTP
#47997 - Automatic Consul Registration for Quarkus Applications
#52090 - OIDC: Support for custom DPoP nonce providers
#52353 - OIDC: Add basic support for rich authorization requests
#52175 - Make built-in authentication mechanism order customizable
#52537 - Introduce OIDC AuthenticationCompletionAction
#52380 - Upgrade to Google Cloud Function framework 2.0

We strongly recommend upgrading to 3.32 soon so we can gather feedback and ensure the upcoming 3.33 LTS is as solid as possible.

If you are currently running 3.27 LTS, now is the right time to validate your upgrade path to 3.33 LTS, and let us know if you encounter any issues. Your feedback at this stage is especially valuable.

Update

To update to Quarkus 3.32, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.32.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.32 migration guide.

変更点

Project Leyden integration

Project Leyden brings Ahead-of-Time (AOT) compilation to the JVM. By recording class loading, class linking, and method profiling during a training run, you can generate an AOT cache file that the JVM can use for subsequent runs.

The result is a significant improvement in JVM startup time, with very few constraints or drawbacks.

Project Leyden is available starting with OpenJDK 25 (counting only LTS releases). We’ll explore it in detail in a dedicated blog post very soon.

In Quarkus, we’ve integrated Project Leyden AOT so that:

The training run can be triggered either at build time (minimal training) or through your integration tests.
The generated AOT cache file can be included directly in your container image.

While the improvements aren’t quite as substantial as with native executables, and the container image size is a bit larger due to the AOT cache file, the results are impressive given the minimal effort required:

A minimal REST application created with quarkus create app sees startup drop from 370 ms to 80 ms.
A large REST CRUD application with 9,000 classes goes from 3 seconds to 900 ms.

You can learn more in the Quarkus AOT guide, and we’ll share a detailed walkthrough in the upcoming blog post.

Graceful shutdown

Several improvements were made to our HTTP graceful shutdown, thanks to some work from the Keycloak team.

Stork

Quarkus applications can now automatically register to Consul, using the Stork extension.

This new feature is explained in detail in the Automatic service registration with SmallRye Stork for Quarkus guide.

セキュリティー

As usual, this version comes with new security features and enhancements:

#52090 - OIDC: Support for custom DPoP nonce providers
#52353 - OIDC: Add basic support for rich authorization requests
#52175 - Make built-in authentication mechanism order customizable
#52537 - Introduce OIDC AuthenticationCompletionAction

Google Cloud Function

The Google Cloud Function framework has been updated to 2.0.

Platform updates

We updated Camel Quarkus to Camel Quarkus 3.32. For more information, see the announcement.

Quarkus CXF was also updated to 3.32. Since we forgot to include the 3.31.1 release notes in previous Quarkus announcements, you can now read both sets of notes: 3.31.1 and 3.32.0.

完全な変更履歴

You can get the full changelog of 3.32.0.CR1, 3.32.0, and 3.32.1 on GitHub.

コントリビューター

The Quarkus community is growing and has now 1163 contributors. Many many thanks to each and everyone of them.

In particular for the 3.32 release, thanks to Ales Justin, Alexander Schwartz, Alexandre Dutra, Alexey Loubyansky, andreatp, Asger Askov Blekinge, Aurea Munoz, Aurélien Pupier, azerr, Bruno Baptista, Carles Arnal, cfitzw, Chris Laprun, Clement Escoffier, Daniel Vergien, David M. Lloyd, Dennis Kniep, Erwin Oegema, Foivos Zakkak, Fouad Almalki, Frank Eichfelder, George Gastaldi, Georgios Andrianakis, Guillaume Smet, Holly Cummins, Jakub Jedlicka, James Netherton, Jerome Prinet, Jiri Ondrusek, jtama, Julien Ponge, Karm Michal Babacek, Katia Aresti, Kristian Rickert, Ladislav Thon, lberrymage, lloydmeta, Loïc Mathieu, Marc Nuri, Marco Belladelli, marco sappe griot, mariofusco, marko-bekhta, Martin Kouba, Martin Panzer, Matej Novotny, Matheus Cruz, melloware, Michael Edgar, Michal Vavřík, Nejc Tomažič, Nicola Concetti, Olivier V, osoohynn, Ozan Gunalp, Patrick Schaub, Peter Levart, Peter Palaga, Phillip Krüger, Robert Stupp, Robert Toyonaga, Roberto Cortez, Sanne Grinovero, Sergey Beryozkin, shjones, sNiXx, Steve Hawkins, Stéphane Épardaud, Teymur Babayev, Victor Dalosto, Vincent Sevel, vincent-duluth, xstefank, and Yoann Rodière.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

How Project Leyden brought a new perspective

Guillaume Smet (https://twitter.com/gsmet_) — Tue, 24 Feb 2026 00:00:00 +0000

This is a story about Project Leyden. And this is not a story about Project Leyden.

It is a story about how Project Leyden gave us a new perspective on how we think about startup performance in Quarkus, and, more broadly, in Java.

It is a story with flamegraphs.

Isn’t it the best kind of story?

Acknowledgments

I shared this journey with my dear colleague Georgios Andrianakis, who was also instrumental in making this happen. And this is exactly the kind of journey you want to share with someone.

How the story started

It all started with me complaining, more than once, that improving startup performance in Quarkus had become really hard. Startup was cluttered with class loading noise. Which means that every time you looked at a startup profile, you clicked on something suspicious and realized:

Oh well, that’s just us loading a class for the first time… bummer.

I’m a patient person. But you only get so many mouse clicks per day.

Then, one day, I took a shower, and I had this idea:

Isn’t Project Leyden supposed to improve the class loading story, among other things?

Maybe we could use it to get rid of the class loading noise and get a clearer picture of what’s really going on during startup?

As it turns out, this was a bit of a rabbit hole. Project Leyden delivered results that were far better than expected, and we ended up working with Georgios on integrating it tightly in Quarkus (you can see another blog post coming, right?).

But today, I promised you flamegraphs. I know you’re all excited about them. Let’s get to it!

Changing the perspective

We’ll explore this in more detail in a future blog post, but for now, suffice it to say that Project Leyden caches classes in a loaded and linked state, along with additional metadata such as method profiling information and, soon, compiled code.

In practice, Project Leyden improves Java startup performance by shifting expensive work, like class loading and linking, into a dedicated training phase. By capturing that state ahead of time, the application can skip much of the redundant setup normally performed at runtime.

In other words, if everything is recorded properly, class loading can be almost entirely taken out of the startup path.

And suddenly, you’re in brand-new territory: the Quarkus REST application you get from a simple quarkus create app starts in 130 milliseconds.

That’s already pretty good, right? But what’s even more interesting is that we were able to do much better (see you in the next blog post, remember?).

And this is where the perspective shifts significantly: when you start in ~ 100 milliseconds, every dozen milliseconds you save becomes a meaningful improvement. You can no longer afford to ignore a 5-millisecond cost.

I can hear someone in the room shouting:

Stop with the words! I want my flamegraphs!

Fine, fine.

How can we improve as an ecosystem?

One extremely important note before we begin: we’re not trying to criticize any library or framework here. We also found some low-hanging fruits in Quarkus itself, we’re all in the same boat here.

The goal of this blog post is to show how Project Leyden helped us uncover things that had been hidden for far too long. And hopefully, this will give other library and framework authors a few useful ideas, and ultimately help improve the Java ecosystem as a whole.

And in the worst case, at least you got your flamegraphs \o/.

Compatibility layers

Figure 1. Netty trying to determine whether virtual threads are available

Many libraries include compatibility layers to support multiple JDK versions. Typically, they rely on reflection to determine whether features like virtual threads are available.

In the Quarkus ecosystem, this is common in low-level libraries such as Netty or Vert.x. But in reality, we see this pattern everywhere.

We should avoid this. It has a cost, and that cost is paid at every single startup of every application using these libraries.

Multi-release JARs are not perfect. They’re harder to maintain, harder to test, and not always well supported by IDEs. But they do solve this problem. And I would argue that, as library and framework authors, it’s our responsibility to ensure the cost is paid once at build time, not at every application startup.

Together with Georgios, we decided to experiment with rewriting the bytecode of some of these libraries at build time to remove the reflective calls and replace them with direct invocations, when the application was targeting a Java version that supports the feature.

It’s a bit of a hack, and definitely not something we want to maintain long term, but it was a great way to validate the idea and score a few quick wins.

Reading annotations

This one isn’t new to us: one of the reasons we wrote Quarkus in the first place was to avoid reading annotations at runtime.

For most of our use cases, we can process annotations at build time and generate the necessary bytecode so there’s no need to inspect them at runtime. Jandex, our annotation indexer, is a fantastic tool for this, and we use it extensively in Quarkus. But… there are still cases where annotations are read at runtime, even in Quarkus.

Why is reading annotations so costly? Because parsing them has a cost. It happens the first time you try to access them at runtime, and the JDK then creates proxy instances to expose the annotation values.

Netty and marker annotations

Figure 2. Netty trying to determine if a ChannelHandler is sharable

The Netty case is particularly interesting because it reads annotations to determine the capabilities of interface implementations.

For this kind of use case, we recommend using marker interfaces or methods instead of annotations.

Georgios once again resorted to bytecode rewriting to eliminate the annotation lookup. Again, this isn’t something we want to maintain in the long term.

Hibernate ORM

Hibernate ORM is also extremely interesting in this context.

The first important point is that, with Hibernate ORM, in Quarkus, we still build the metadata at runtime. That means we end up reading a lot of annotations at runtime. A long-term effort has already started to improve this situation, but it’s a significant undertaking and will take time before we can move metadata building to build time instead.

Let’s set that aside for now.

What’s also interesting is that Hibernate ORM collects metadata about its own annotations at runtime, both Hibernate-specific annotations and JPA annotations. And that’s a lot of annotations, and a lot of metadata to process.

Figure 3. Hibernate ORM collecting metadata about its own annotations

For example, for each JPA or Hibernate annotation, it determines the annotation target (class, method, field), or whether it is inherited.

In the end, this results in a substantial amount of annotation processing for something that changes very rarely.

I identified this issue some time ago, and our colleague Luca Molteni from the Hibernate team will be looking into it soon. We’re not yet sure how easy it will be to fix, but you get the idea. Whenever possible, this kind of metadata should be resolved once and for all. And you should be able to enforce its correctness with tests to ensure it remains accurate and up to date.

Hopefully, we’ll be able to improve this soon. And the nice part is that any improvement here will benefit all applications using Hibernate ORM, not just Quarkus applications.

The new cost of loading

When not using Leyden, you load a gazillion classes. JAR files are opened anyway, that’s "fine". Well, depending on your definition of "fine".

When using Leyden, you can reach a point where no classes are loaded at startup at all.

Which means that anything attempting to load something from the classpath will trigger JAR files to be opened (the first time they are accessed), and then read from disk.

And you can be sure that some resources will be loaded from your classpath:

ServiceLoader service files (the ones in META-INF/services/), used by the JDK and many libraries and frameworks to discover interface implementations;
Configuration files;
And probably many other things.

Non-existing classes and resources

Why would you try to load a non-existing class? That’s a good question.

Figure 4. Hibernate ORM trying to load non-existing package-info

Remember package-info.java files? Hibernate ORM, for instance, tries to load them to inspect package-level annotations. In a lot of cases, these files don’t exist, and that’s perfectly normal.

Caching class loading is within the scope of Leyden, but Leyden does not cache negative lookups. Why? Because Leyden, while AOT, is still true Java. Java is a dynamic language: even if a class wasn’t present when you recorded the cache, it might be added later. Now, in practice, that’s often not the case, especially in Quarkus, where we assume a closed world, but Leyden cannot rely on that assumption.

In Quarkus, when using Leyden, we decided to generate empty package-info classes for all packages containing entities that don’t already have one. This way, Hibernate ORM doesn’t have to attempt to load non-existing classes.

Figure 5. JBoss Logging loading a non-existing class

Another example is JBoss Logging internationalization: it attempts to load a class for the current locale, and if that class doesn’t exist, it falls back to the default class.

You see similar patterns with resources. An application might try to load a configuration file or a service descriptor that doesn’t exist. That’s perfectly normal, the only way to know it’s missing is to try.

In Quarkus, we have a few class loader tricks to mitigate this. But in the general case, you have to deal with it.

And here’s the catch: for all these cases, the runtime will walk the entire classpath (remember, it won’t find anything), trying to locate the class or resource. In doing so, it may open a large number of JAR files and read from them, just to conclude that the class or resource doesn’t exist.

Granted, it doesn’t read the entire JAR, each archive has an index, but still.

ServiceLoader

Figure 6. A ServiceLoader storm

Let’s look at the ServiceLoader case in more detail, it’s particularly interesting.

Once class loading is out of the picture, it becomes clear that a significant portion of startup time is spent loading service descriptors from JAR files. We managed to improve this for some services using a class loader trick, but that only works for services loaded through the thread context class loader. We don’t yet have a good solution for services loaded by the JDK class loaders. At least not for now.

We’ll go into more detail in the next blog post, where we’ll talk more about Project Leyden itself and how we integrated it into Quarkus. Stay tuned.

Some other fun facts

UUID generation

Figure 7. Generating a UUID for the first time

This one is easy: whenever you generate a UUID, the JDK will initialize a SecureRandom instance. And initializing a SecureRandom instance doesn’t come for free, oh no.

Sure, if your application ends up needing a SecureRandom anyway, you don’t care. But if it doesn’t, having your favorite framework generate UUIDs for internal use is not ideal.

Obviously, if your application genuinely needs UUID generation, go ahead and use it.

BigDecimal

Figure 8. Initialization of BigDecimal

In the same vein, the BigDecimal class has a static initializer that actually performs a fair amount of work. Initializing BigDecimal can take a noticeable amount of time.

We stumbled upon this because we were using BigDecimal to perform some calculations when printing the Quarkus startup time.

D’oh.

We replaced that code, only to discover another issue: BigDecimal was also being eagerly initialized in Hibernate ORM for a very narrow use case in the DurationJavaType class. That has since been fixed as well.

Just like with UUIDs, if your application genuinely needs BigDecimal, you should use it and pay the cost.

This is about avoiding the cost when you don’t actually need it.

Time zones

Figure 9. Loading the time zone database

We all know time zones are hard. But now we also know that loading them is slow.

The time zone database is quite large, and loading it, for example when calling TimeZone.getDefault(), can take a noticeable amount of time.

Who would need a time zone in a server application, right? For instance, your logging layer, which wants to print timestamps in the local time zone.

Figure 10. Loading the zone rules

And what’s also interesting is that there’s an additional cost for transforming the time zone to a ZoneId, as you also have to load the zone rules.

These two issues still exist and I have no idea if we can even solve them, but we were able to mitigate their cost somewhat in Quarkus when using the specific packaging we developed for AOT.

まとめ

This post is about the work we did in Quarkus and the libraries Quarkus relies on. But I would argue that the lessons we learned are applicable across the entire Java ecosystem.

I hope that by sharing our experience, we can inspire other projects, especially library and framework authors, to take a similar approach and improve their startup performance.

And to be honest, this isn’t just about improving startup performance, it’s also about reducing the resources wasted during startup. We often talk about Green IT; let’s make our libraries and frameworks greener, especially in cases where it’s simple to achieve.

We’ve shared some of our findings and recipes, but I’m sure there are others that are specific to each library and framework. Now is a great time to look at your own startup profiles and see if you can spot some low-hanging fruit to boost performance. And with Quarkus 3.32 and our new AOT integration coming soon, this is going to be easier than ever.

If you have questions, you know where to find us, and if you find something interesting, please share it with us, we’d love to hear about it!

Onwards!

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

A Go CEL Policy Engine in Java, with Quarkus Chicory

Fabio Burzigotti — Thu, 19 Feb 2026 00:00:00 +0000

A few days ago, we released the first version of Quarkus Chicory, an extension that brings the power of the Chicory WebAssembly runtime to Quarkus applications.

While iterating on development, we felt the need to implement an integration test based on a real world use case.

After some research and experiments on popular scenarios we finally landed on a tasty one :-)

A Kubernetes-style CEL Policy Engine

CEL allows expression based policy validation of Kubernetes resources, and this requirement is implemented by operators… which are generally written in Go :-)

But Quarkus Java based operators exist too - like the Keycloak operator - so what? Are we forced to implement a CEL policy validation engine in Java, from scratch? Or should we find a suitable Java library, for example https://github.com/projectnessie/cel-java?

None of the above: this is where Chicory, a WebAssembly runtime for Java, comes to help.

Let’s just re-use a broadly used and well tested Go library, calling exported functions from Java, in a sandboxed, secure way, and be happy with it!

Why?

no rewrites
low maintenance
1:1 behavior

A Chicory extension for Quarkus applications

Chicory is an open-source, 100% native Java WebAssembly (Wasm) runtime.

Its primary goal is to allow Java developers to run Wasm modules within the JVM, without relying on native libraries, JNI (Java Native Interface) usage, or unsafe code.

Unlike other Wasm runtimes that require platform-specific binaries, Chicory is pure Java.

It executes Wasm code within the JVM’s memory space, providing a "double sandbox" effect (Wasm isolation + JVM security). It also provides WASI (WebAssembly System Interface) support, that allows Wasm modules to interact with system resources safely. Finally, it includes both an interpreter and a runtime compiler for quick execution, in addition to a build-time compiler that converts Wasm into Java bytecode for optimal performance, see Chicory execution modes.

It is ideal for plugin systems, allowing users to write safe plugins in any language (Rust, C++, Go, etc.) that compiles to Wasm, and running them inside a Java app. It can be used for Serverless/Edge Computing cases, as it provides a mean to run lightweight logic on Java-based infrastructure without the overhead of application containers.

And for something that never gets old, i.e. cross-platform portability, your application remains "Write Once, Run Anywhere", without managing different .so or .dll files for different architectures.

You can learn more about Chicory, but from now on let’s focus on its Quarkus extension, here. :-)

Quarkus Chicory brings Chicory to Quarkus application developers, integrating its features into the Quarkus ecosystem and applications build-time and runtime peculiarities, for a natural developer experience. It just… works!

特徴

Build-Time Code Generation

Generates Java bytecode from WebAssembly modules, thus replacing the Chicory Maven plugin.

Dependency Management

Automatically handles version alignment between Quarkus and Chicory’s ASM dependencies.

Multi WASM Module Support

Configure and manage multiple WebAssembly modules.

Dynamic Loading

Manage runtime-loaded WASM modules.

Intelligent Execution Mode Selection

Configures the MachineFactory and WasmModule instances based on the environment. MachineFactory can leverage build-time generated bytecode for optimal performance in production/native, and use runtime or interpreter mode during development or test. Similarly, WasmModule instances can be initialized with WASM metadata rather than pure WASM payload, again for better performance and memory footprint, by leveraging the build-time code generation process.

Live Reload in Development

Static modules are automatically watched and reloaded. Think of everyone’s favorite quarkus:dev, but with Rust and Go modules

Native Image Compatibility
WASM/WASI support

With such potential in our hands, we chose the popular Google CEL, a Go library/API adopted by several Go operators, and decided to integrate it in our application.

Application setup and configuration

Creating the application is straightforward using the Quarkus Maven plugin. Note that Quarkus 3.x requires Java 17 or higher (we used Java 21 for this example):

mvn io.quarkus.platform:quarkus-maven-plugin:create \
    -DprojectGroupId=io.quarkiverse.chicory.demo \
    -DprojectArtifactId=quarkus-cel-k8s-validator \
    -Dextensions='rest'

Next, we add the Quarkus Chicory extension to our pom.xml:

    <properties>
        <dylibso.version>1.6.1</dylibso.version>
        <quarkus-chicory.version>0.0.1</quarkus-chicory.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>${quarkus.platform.group-id}</groupId>
                <artifactId>${quarkus.platform.artifact-id}</artifactId>
                <version>${quarkus.platform.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>com.dylibso.chicory</groupId>
                <artifactId>wasi</artifactId>
                <version>${dylibso.version}</version>
            </dependency>
            <dependency>
                <groupId>io.quarkiverse.chicory</groupId>
                <artifactId>quarkus-chicory</artifactId>
                <version>${quarkus-chicory.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-rest</artifactId>
        </dependency>
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-rest-jackson</artifactId>
        </dependency>
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-arc</artifactId>
        </dependency>
        <dependency>
            <groupId>io.quarkiverse.chicory</groupId>
            <artifactId>quarkus-chicory</artifactId>
        </dependency>
        <dependency>
            <groupId>com.dylibso.chicory</groupId>
            <artifactId>wasi</artifactId>
        </dependency>
        <!-- more dependencies here... -->
    </dependencies>

Finally, the WASM module configuration goes in application.properties:

quarkus.chicory.modules.go-cel.name=io.quarkiverse.chicory.demo.GoCelModule
quarkus.chicory.modules.go-cel.wasm-file=src/main/resources/wasm/go-cel.wasm

This tells Quarkus Chicory to generate a GoCelModule class at build time from the specified WASM file. The extension will automatically generate Java bytecode from the WebAssembly module, configure the appropriate MachineFactory based on the runtime environment, and - in development mode - watch the WASM file for changes to trigger live reload.

One last step, now. We will use the WasmModuleInterface annotation and configure the annotation processor, for Chicory to generate a Java class containing methods mapping 1:1 to Go exported functions.

First, let’s create a K8sCel Java class where to place our annotation:

package io.quarkiverse.chicory.demo;

import com.dylibso.chicory.annotations.WasmModuleInterface;

@WasmModuleInterface(WasmResource.absoluteFile)
public class K8sCel {

    private K8sCel() {}

}

At build-time, the Chicory annotation processor will discover such annotation and generate a K8sCel_ModuleExports class, which provides the exported methods:

package io.quarkiverse.chicory.demo;

import com.dylibso.chicory.runtime.ExportFunction;
import com.dylibso.chicory.runtime.Instance;
import com.dylibso.chicory.runtime.Memory;

public class K8sCel_ModuleExports {
    private final ExportFunction field__start;
    private final ExportFunction field_malloc;
    private final ExportFunction field_free;
    private final ExportFunction field_evalPolicy;
    private final Memory field_memory;

    public K8sCel_ModuleExports(Instance instance) {
        this.field__start = instance.exports().function("_start");
        this.field_malloc = instance.exports().function("malloc");
        this.field_free = instance.exports().function("free");
        this.field_evalPolicy = instance.exports().function("evalPolicy");
        this.field_memory = instance.exports().memory("memory");
    }

    public void _start() {
        this.field__start.apply(new long[0]);
    }

    public int malloc(int arg0) {
        long result = this.field_malloc.apply(new long[]{(long)arg0})[0];
        return (int)result;
    }

    public void free(int arg0) {
        this.field_free.apply(new long[]{(long)arg0});
    }

    public int evalPolicy(int arg0, int arg1, int arg2, int arg3) {
        long result = this.field_evalPolicy.apply(new long[]{(long)arg0, (long)arg1, (long)arg2, (long)arg3})[0];
        return (int)result;
    }

    public Memory memory() {
        return this.field_memory;
    }
}

And that’s enough!

The `WasmQuarkusContext` API

The example application follows a clean architecture pattern with separated concerns:

K8sCelValidatorService - Manages WASM integration and business logic
K8sCelValidatorResource - Provides REST API endpoint

The Quarkus Chicory extension provides the WasmQuarkusContext API for injection, to access configured WASM modules. Here’s how we use it in our service:

@ApplicationScoped
public class K8sCelValidatorService {

    @Inject
    @Named("go-cel")
    WasmQuarkusContext wasmQuarkusContext;

    Instance instance;
    K8sCel_ModuleExports exports;

    @PostConstruct
    public void init() throws IOException {
        WasmModule wasmModule = wasmQuarkusContext.getWasmModule();
        if (wasmModule == null) {
            throw new IllegalStateException("Wasm module " + wasmQuarkusContext.getName() + " not found!");
        }

        // Create WASI support for stdout/stderr
        WasiOptions options = WasiOptions.builder()
                .withStdout(new ByteArrayOutputStream())
                .withStderr(new ByteArrayOutputStream())
                .build();
        WasiPreview1 wasi = WasiPreview1.builder()
                .withOptions(options)
                .build();
        Store store = new Store().addFunction(wasi.toHostFunctions());

        instance = Instance.builder(wasmModule) (1)
                .withMachineFactory(wasmQuarkusContext.getMachineFactory())
                .withImportValues(store.toImportValues())
                // Don't auto-run _start(), we'll call it manually
                .withStart(false)
                .build();

        // Get exported functions BEFORE calling _start
        exports = new K8sCel_ModuleExports(instance);   (2)

        // Initialize Go runtime by calling _start()
        // This is required to perform initialization, i.e. to run main(), which indeed should exit with 0,
        // so we catch the expected WasiExitException accordingly.
        try {
            exports.start();    (3)
        } catch (com.dylibso.chicory.wasi.WasiExitException e) {
            // Expected - Go main() exits after completing
            if (e.exitCode() != 0) {
                throw new RuntimeException("Go runtime initialization failed with exit code: " + e.exitCode());
            }
            // Exit code 0 is success - runtime is now initialized and exported functions are ready
        }
    }

    public ValidationResult validate(final String resourceJson, final String celPolicy) {

        byte[] policyBytes = celPolicy.getBytes(StandardCharsets.UTF_8);
        byte[] inputBytes = resourceJson.getBytes(StandardCharsets.UTF_8);

        // Allocate memory for policy string in WASM
        int policyPtr = exports.malloc(policyBytes.length);
        if (policyPtr == 0) {
            throw new IllegalStateException("Failed to allocate memory for policy");
        }

        // Allocate memory for input JSON in WASM
        int inputPtr = exports.malloc(inputBytes.length);
        if (inputPtr == 0) {
            throw new IllegalStateException("Failed to allocate memory for input");
        }

        try {
            // Write policy and input to WASM memory
            exports.memory().write(policyPtr, policyBytes);
            exports.memory().write(inputPtr, inputBytes);

            // Call evalPolicy(policyPtr, policyLen, inputPtr, inputLen)
            int returnCode = exports.evalPolicy(policyPtr, policyBytes.length, inputPtr, inputBytes.length);

            // Interpret result
            if (returnCode == 11) {
                return new ValidationResult(VALIDATION_RESULT_ALLOWED, "Policy ALLOWS the request", celPolicy);
            } else if (returnCode == 0) {
                return new ValidationResult(VALIDATION_RESULT_DENIED, "Policy DENIES the request", celPolicy);
            } else {
                // Negative values are errors
                String errorMsg = switch (returnCode) {
                    case -1 -> "JSON parse error";
                    case -2 -> "CEL environment creation error";
                    case -3 -> "CEL compilation error";
                    case -4 -> "CEL program creation error";
                    case -5 -> "CEL runtime error";
                    default -> "Unknown error: " + returnCode;
                };
                return new ValidationResult(VALIDATION_RESULT_ERROR, "CEL evaluation failed: " + errorMsg, celPolicy);
            }
        } finally {
            // Free allocated memory in WASM
            exports.free(policyPtr);
            exports.free(inputPtr);
        }
    }

    public static final String VALIDATION_RESULT_ALLOWED = "allowed";
    public static final String VALIDATION_RESULT_DENIED = "denied";
    public static final String VALIDATION_RESULT_ERROR = "error";

    public record ValidationResult(String status, String message, String policy) {}
}

1	The injected `WasmQuarkusContext` bean configures `Instance.Builder` to use `MachineFactory` and `WasmModule` instances, which are created dynamically, based on the application configuration and execution environment.
2	Once `instance` is built, `export` is initialized with a `K8sCel_ModuleExports` instance, providing exported functions which are called later in the `validate()` method.
3	The exported "_start" function is called, to initialize the Go runtime. This executes the Go program `main()` function. As it’s empty in our implementation, it will exit immediately, so we catch `WasiExitExcpetion` to check for a 0 (no errors) exit code.

A note about multi-user and thread safety

WasmQuarkusContext instances are injected as @ApplicationScoped beans. This means that a unique application instance can be used by several clients (or user requests) and threads. That being said, the API implementation is stateless, i.e. getMachineFactory() and getWasmModule() always return new instances.

The way such instances are dealt with, and how their lifecycle is orchestrated, is something that pertains to the application domain. For example, the above implementation doesn’t take concurrency into account. If multiple threads are going to consume the same Memory instance, a thread-safe implementation would be required in order to avoid corrupting the shared WasmModule linear memory.

Back to our application code, the REST resource is then a simple delegation layer:

@Path("/k8s")
public class K8sCelValidatorResource {

    @Inject
    K8sCelValidatorService validatorService;

    @POST
    @Path("/validate")
    public Response validate(@RestForm String resourceJson, @RestForm String celPolicy) {
        ValidationResult result = validatorService.validate(resourceJson, celPolicy);

        Response.Status status = switch (result.status()) {
            case "allowed" -> Response.Status.OK;
            case "denied" -> Response.Status.FORBIDDEN;
            default -> Response.Status.BAD_REQUEST;
        };

        return Response.status(status).entity(result).build();
    }
}

The WasmQuarkusContext API provides two key methods:

getWasmModule(): returns the parsed WebAssembly module
getMachineFactory(): returns the appropriate MachineFactory based on environment (interpreter for dev, build-time compilation for production/native)

The @Named qualifier matches the module name from application.properties. The extension handles all the complexity of WASM module lifecycle, allowing us to focus on the business logic.

How it works: Go → Wasm → Java bytecode

The heart of our application is the Go CEL implementation, compiled to WebAssembly. The Go code implements three key exported functions:

//go:wasmexport evalPolicy
func evalPolicy(policyPtr, policyLen, inputPtr, inputLen uint32) int32 {
    // Convert pointers to Go types
    policy := unsafe.String((*byte)(unsafe.Pointer(uintptr(policyPtr))), policyLen)
    inputJSON := unsafe.Slice((*byte)(unsafe.Pointer(uintptr(inputPtr))), inputLen)

    // Parse the JSON input
    var input map[string]any
    if err := json.Unmarshal(inputJSON, &input); err != nil {
        return -1  // JSON parse error
    }

    // Create CEL environment
    env, err := cel.NewEnv(
        cel.Declarations(
            decls.NewVar("object", decls.NewMapType(decls.String, decls.Dyn)),
        ),
    )
    if err != nil {
        return -2  // CEL environment creation error
    }

    // Compile and evaluate the CEL expression
    ast, iss := env.Compile(policy)
    if iss.Err() != nil {
        return -3  // Compilation error
    }

    prg, err := env.Program(ast)
    if err != nil {
        return -4  // Program creation error
    }

    out, _, err := prg.Eval(map[string]any{"object": input})
    if err != nil {
        return -5  // CEL runtime error
    }

    // Return 1 for allow, 0 for deny
    if b, ok := out.Value().(bool); ok && b {
        return 1
    }
    return 0
}

This Go code is compiled to WASM using the WASI target:

GOOS=wasip1 GOARCH=wasm go build -o go-cel.wasm main.go

In our service implementation:

Java allocates WASM memory for the policy string and input resource manifest (JSON), and writes the data to WASM memory
Java calls evalPolicy() with pointers to arguments and their size
Go code reads from its memory space, and evaluates the CEL expression using the Google CEL library
Go returns an integer result code (1=allow, 0=deny, negative=error)
Java interprets the result and performs clean up

This demonstrates the power of WebAssembly: we can use the mature, battle-tested Google CEL-Go library from Java without reimplementing CEL from scratch.

The WASM boundary provides a clean and safe interface between the two languages.

In production, we can write CEL policies that validate Kubernetes resources just like Go operators do:

// Require production label
has(object.metadata.labels.env) && object.metadata.labels.env == "production"

// Deny privileged containers
!(has(object.spec.containers) && object.spec.containers.exists(c,
  has(c.securityContext) && c.securityContext.privileged == true))

// Require resource limits
has(object.spec.containers) && object.spec.containers.all(c,
  has(c.resources) && has(c.resources.limits))

まとめ

By combining Quarkus Chicory with Google CEL-Go compiled to WebAssembly, we’ve created a Kubernetes-style CEL policy engine that runs entirely in Java.

This approach offers several benefits:

Reuse existing Go libraries: No need to reimplement CEL in Java, 1:1 mapping with original Go code
Type safety and performance: Quarkus Chicory generates Java bytecode from WASM modules
Production ready: The same CEL library used by Go operators, now available in Java
Developer experience: Live reload, build-time code generation, and native image support
Ecosystem compatibility: Works seamlessly with Java-based Kubernetes operators

This demonstrates that WebAssembly is not just a browser technology, but rather a powerful tool for cross-language interoperability in cloud-native applications, and showcases how to integrate this workflow easily in Quarkus applications, thanks to Quarkus Chicory.

For Java developers building Kubernetes operators, this approach opens up a large part of the Go ecosystem without leaving the JVM.

You can find the complete working example at: https://github.com/fabiobrz/quarkus-cel-k8s-validator

参照

Quarkus 3.31.4 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 18 Feb 2026 00:00:00 +0000

Today, we released Quarkus 3.31.4, the third maintenance release for our 3.31 stream (we skipped 3.31.0).

Update

To update to Quarkus 3.31, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.31.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.31 migration guide.

完全な変更履歴

You can get the full changelog of 3.31.4 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus Newsletter #65 - February

James Cobb (https://twitter.com/insectengine) — Fri, 13 Feb 2026 00:00:00 +0000

Although focused on microservices, Quarkus is also perfectly suited for large monoliths, whether you are migrating existing applications to a more modern runtime or building new ones from scratch. Quarkus has always been able to handle large applications, but we have recently made significant improvements in this area, particularly when it comes to build times. Read "Towards faster builds" by Guillaume Smet to learn more about these improvements. Read "Implementing an arXiv MCP Server with Quarkus in Java" by Guillaume Laforge to learn about building an MCP server to access the arXiv research paper website where pre-print versions are published and shared with the community. The author’s goal was to shed light on some lesser-known aspects of the Model Context Protocol, tools, resources and prompts. Learn the details of why Anand Jaisy chose to switch frameworks in "Micronaut vs Quarkus: Why I Switched After Two Years". Check out "How to Trace Quarkus Reactive Messaging with OpenTelemetry" by Nawaz Dhandala to learn how to implement distributed tracing for Quarkus Reactive Messaging applications using OpenTelemetry to track messages across Kafka and other messaging systems. Make sure you try this realistic Java walkthrough showing validation, retries, idempotency, and Kafka-backed workflows with Quarkus in "Your Second Reactive Messaging App: What Production Systems Actually Need" by Markus Eisele. Then you can learn about using graph-based analysis to detect and prevent architectural decay in Java applications in his second blog post, "Your Quarkus Architecture Is Drifting. JQAssistant Can Prove It."

You will also see the latest Quarkus Insights episodes, top tweets/discussions and upcoming Quarkus attended events.

Check out Newsletter #65: February!

ニュースレターを受信してみませんか？ページ上のフォームを使ってニュースレターに登録してください。

A2A Java SDK 1.0.0.Alpha2 Released

Emmanuel Hugonnet (https://twitter.com/ehsavoie) — Thu, 12 Feb 2026 00:00:00 +0000

We are pleased to announce the release of A2A Java SDK 1.0.0.Alpha2. This release brings significant new features and improvements as we continue to align with the A2A 1.0 specification.

What’s A2A?

The Agent2Agent (A2A) Protocol is an open standard that enables AI agents to communicate and collaborate with one another, regardless of each agent’s underlying framework, language, or vendor. The A2A Java SDK makes it easy to build A2A-compliant agents in Java, with reference implementations based on Quarkus.

Key Highlights in 1.0.0.Alpha2

This release includes several important enhancements and breaking changes:

New Features

Telemetry Support

The A2A Java SDK now includes built-in support for telemetry using OpenTelemetry. This allows you to monitor and trace your agent’s operations, making it easier to diagnose issues and understand performance characteristics.

To use the telemetry features, add the OpenTelemetry extras to your project:

<dependency>
    <groupId>io.github.a2asdk</groupId>
    <artifactId>a2a-java-sdk-extras-opentelemetry-client</artifactId>
    <version>1.0.0.Alpha2</version>
</dependency>
<dependency>
    <groupId>io.github.a2asdk</groupId>
    <artifactId>a2a-java-sdk-extras-opentelemetry-server</artifactId>
    <version>1.0.0.Alpha2</version>
</dependency>

Push Notifications

We’ve implemented full support for push notifications as specified in the A2A 1.0 specification. This allows agents to receive notifications about task updates without polling.

Server agents can now:

Configure push notification endpoints
Manage push notification configurations per task
Receive notifications when task states change

Clients can:

Get, set, list, and delete push notification configurations
Subscribe to task updates via push notifications

Protocol Updates

Breaking Changes

This release includes breaking changes to align with the latest A2A specification.

AgentEmitter API: The AgentExecutor methods now use AgentEmitter instead of the previous EventQueue + TaskUpdater combination, providing a more streamlined and intuitive API. This enhancement allows sending Messages for simple Agent interactions directly through the AgentEmitter, eliminating the need to interact with the EventQueue directly.
Protocol Alignment: Updated the A2A protocol implementation to align with the latest specification revision, including updates to the gRPC protocol definitions.

Additional Improvements

Null-Safety: Migrated the spec module to use JSpecify annotations for better null-safety guarantees
Jakarta CDI Compatibility: Added no-args constructors for improved Jakarta CDI compatibility
HTTP+JSON/REST Transport: Replaced quarkus-rest-jackson with quarkus-rest for better integration
Event Processing: Implemented the MainEventBus architecture for more robust event queue processing
MicroProfile Config: Added missing META-INF/beans.xml to the microprofile-config integration

移行ガイド

If you’re upgrading from 1.0.0.Alpha1, you’ll need to make the following changes:

Update AgentExecutor Implementation

The execute and cancel methods now receive an AgentEmitter parameter instead of EventQueue:

// Before (1.0.0.Alpha1)
@Override
public void execute(RequestContext context, EventQueue eventQueue) throws JSONRPCError {
    final TaskUpdater updater = new TaskUpdater(context, eventQueue);
    updater.submit();
    updater.startWork();
    // ...
}

// After (1.0.0.Alpha2)
@Override
public void execute(RequestContext context, AgentEmitter agentEmitter) throws JSONRPCError {
    agentEmitter.submit();
    agentEmitter.startWork();
    // ...
}

The AgentEmitter interface provides the same functionality with a cleaner API.

はじめに

To use A2A Java SDK 1.0.0.Alpha2, add the appropriate dependencies to your project:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.github.a2asdk</groupId>
            <artifactId>a2a-java-sdk-bom</artifactId>
            <version>1.0.0.Alpha1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<!-- For JSON-RPC transport -->
<dependency>
    <groupId>io.github.a2asdk</groupId>
    <artifactId>a2a-java-sdk-reference-jsonrpc</artifactId>
    <version>1.0.0.Alpha2</version>
</dependency>

<!-- For gRPC transport -->
<dependency>
    <groupId>io.github.a2asdk</groupId>
    <artifactId>a2a-java-sdk-reference-grpc</artifactId>
    <version>1.0.0.Alpha2</version>
</dependency>

<!-- For HTTP+JSON/REST transport -->
<dependency>
    <groupId>io.github.a2asdk</groupId>
    <artifactId>a2a-java-sdk-reference-rest</artifactId>
    <version>1.0.0.Alpha2</version>
</dependency>

リソース

まとめ

A2A Java SDK 1.0.0.Alpha2 represents a significant step forward in our journey toward full A2A 1.0 specification compliance. The addition of telemetry support and push notifications makes it easier to build production-ready agents, while the protocol updates ensure compatibility with the latest specification.

We encourage you to try out this release and provide feedback through our GitHub issue tracker. Your input helps shape the future of the A2A Java SDK.

Quarkus 3.31.3 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 11 Feb 2026 00:00:00 +0000

Today, we released Quarkus 3.31.3, the second maintenance release for our 3.31 stream (we skipped 3.31.0).

Update

To update to Quarkus 3.31, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.31.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.31 migration guide.

完全な変更履歴

You can get the full changelog of 3.31.3 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Closing the Gap: Test Coverage for Quarkus Extensions

Martin Kouba (https://twitter.com/martunek) — Tue, 10 Feb 2026 00:00:00 +0000

Test coverage is usually defined as a metric that measures the percentage of code executed by tests. Some developers doubt its usefulness but I agree with Martin Fowler’s opinion that "Test coverage is a useful tool for finding untested parts of a codebase". I don’t think the resulting number itself is important. After all, writing a test for a generated getter makes no sense at all. However, if it’s possible to identify poorly tested code in a hot path of your extension, then you can improve the test suite and spot bugs before the release, which always pays off. Just as importantly, you can increase the ability to catch regressions.

For a long time, there has been the io.quarkus:quarkus-jacoco extension that integrates the JaCoCo code coverage library. Nevertheless, until recently, it was not possible to measure the coverage of runtime modules for an extension project. In other words, it was possible to measure the coverage in your `@QuarkusTest`s but not in `QuarkusUnitTest`s, which typically constitute the majority of tests in extensions. Without adequate coverage support, developers were flying blind, uncertain whether their bytecode enhancements and recording logic were being effectively tested.

Technical overview

JaCoCo instruments classes to record execution coverage data. By default, the classes are instrumented on-the-fly by a Java agent. However, in Quarkus we use offline instrumentation to modify the bytecode of classes during build. By default, all classes in all application archives are instrumented. An application archive is an archive that provides components to the application. It’s indexed via Jandex, and extensions can analyze its content. For example, Quarkus is analyzing the application archives during CDI bean discovery. However, a runtime module of an extension is usually not an application archive. Therefore, the extension classes were never instrumented. Until now. In Quarkus 3.31.2, we introduced new configuration properties that specify the artifacts to be instrumented: quarkus.jacoco.instrument-artifacts."dependency-name".group-id and quarkus.jacoco.instrument-artifacts."dependency-name".artifact-id.

Basic setup

If you want to measure the test coverage of the runtime module of an extension, specific JaCoCo configuration is needed in the deployment module:

<profiles>
    <profile>
        <id>test-coverage</id>
        <activation>
            <property>
                <name>jacoco</name> (1)
            </property>
        </activation>
        <dependencies>
            <dependency>
                <groupId>io.quarkus</groupId>
                <artifactId>quarkus-jacoco-deployment</artifactId> (2)
                <scope>test</scope>
            </dependency>
        </dependencies>
        <build>
            <plugins>
                <plugin>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <configuration>
                        <systemPropertyVariables>
                            <quarkus.jacoco.instrument-artifacts.runtime.group-id>io.quarkus</quarkus.jacoco.instrument-artifacts.runtime.group-id>
                            <quarkus.jacoco.instrument-artifacts.runtime.artifact-id>quarkus-runtime-module-name</quarkus.jacoco.instrument-artifacts.runtime.artifact-id> (3)
                        </systemPropertyVariables>
                    </configuration>
                </plugin>
            </plugins>
        </build>
    </profile>
</profiles>

1	This profile is activated with the `jacoco` property.
2	Add the `quarkus-jacoco-deployment` dependency with the test scope.
3	Instruct the JaCoCo plugin to instrument the io.quarkus:quarkus-runtime-module-name` artifact.

By default, the JaCoCo data will be saved in the target/jacoco-quarkus.exec file and a coverage report is generated automatically in the target/jacoco-report directory.

Multi-module setup

For multi-module projects, more config properties might be needed. Typically, when an extension project contains multiple extensions that depend on each other, a more complex configuration is required. In the following project we have two extensions submodules: foo and bar.

/my-extension-project
   ├── /foo
   │  ├── runtime
   │  ├── deployment
   │  └── pom.xml
   ├── /bar (depends on foo)
   │  ├── runtime
   │  ├── deployment
   │  └── pom.xml
   └── pom.xml

Submodule bar depends on foo and extends its functionality. The foo/deployment submodule contains QuarkusUnitTest`s that test classes from `foo/runtime. The bar/deployment submodule contains QuarkusUnitTest`s that test classes from both `bar/runtime and foo/runtime.

Our goal is to measure the coverage for both foo/runtime and bar/runtime. How do we proceed? First, we need to apply some configuration to the parent project.

my-extension-project/pom.xml

<profiles>
    <profile>
        <id>test-coverage</id>
        <activation>
            <property>
                <name>jacoco</name> (1)
            </property>
        </activation>
        <build>
            <plugins>
                <plugin>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <configuration>
                        <systemPropertyVariables>
                           <quarkus.jacoco.data-file>${maven.multiModuleProjectDirectory}/target/jacoco.exec</quarkus.jacoco.data-file> (2)
                           <quarkus.jacoco.reuse-data-file>true</quarkus.jacoco.reuse-data-file> (3)
                           <quarkus.jacoco.report-location>${maven.multiModuleProjectDirectory}/target/coverage</quarkus.jacoco.report-location> (4)
                           <quarkus.jacoco.aggregate-report-data>true</quarkus.jacoco.aggregate-report-data> (5)
                        </systemPropertyVariables>
                    </configuration>
                </plugin>
            </plugins>
        </build>
    </profile>
</profiles>

1	This profile is activated with the `jacoco` property.
2	The shared JaCoCo data file will be: `my-extension-project/target/jacoco.exec`.
3	The shared JaCoCo data will be reused for all tests.
4	The generated coverage report will be in the `my-extension-project/target/coverage` directory.
5	The report data (source directories and class files) are aggregated so that a single report can be generated.

Afterwards, we will modify the deployment modules of foo and bar.

my-extension-project/bar/pom.xml

<profiles>
   <profile>
      <id>test-coverage</id>
      <activation>
         <property>
            <name>jacoco</name> (1)
         </property>
      </activation>
      <dependencies>
         <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-jacoco-deployment</artifactId>
            <scope>test</scope>
         </dependency>
      </dependencies>
      <build>
         <plugins>
            <plugin>
               <artifactId>maven-surefire-plugin</artifactId>
               <configuration>
                  <systemPropertyVariables>
                     <quarkus.jacoco.instrument-artifacts.foo.group-id>org.acme</quarkus.jacoco.instrument-artifacts.foo.group-id>
                     <quarkus.jacoco.instrument-artifacts.foo.artifact-id>foo</quarkus.jacoco.instrument-artifacts.foo.artifact-id> (2)
                     <quarkus.jacoco.instrument-artifacts.bar.group-id>org.acme</quarkus.jacoco.instrument-artifacts.bar.group-id>
                     <quarkus.jacoco.instrument-artifacts.bar.artifact-id>bar</quarkus.jacoco.instrument-artifacts.bar.artifact-id> (3)
                  </systemPropertyVariables>
               </configuration>
            </plugin>
         </plugins>
      </build>
   </profile>
</profiles>

1	This profile is activated with the `jacoco` property.
2	Instrument `org.acme:foo` when running tests in `bar/deployment`.
3	Instrument `org.acme:bar` when running tests in `bar/deployment`.

Similarly, we can modify the my-extension-project/foo/pom.xml and then simply run mvn clean test -Djacoco. When the build is finished, we can analyze the code coverage reports in the my-extension-project/target/coverage directory.

The Quarkus JaCoCo config only works for tests that are annotated with @QuarkusTest and @QuarkusUnitTest. If you want to check the coverage of other tests as well then you will need to fall back to the JaCoCo maven plugin, see the docs for more information.

まとめ

Since Quarkus 3.31.2 you can measure and analyze the code coverage for the runtime modules of Quarkus extensions. Improve the test suite, spot more bugs before the release, catch more regressions!

Quarkus 3.31.2 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 04 Feb 2026 00:00:00 +0000

Today, we released Quarkus 3.31.2, the first maintenance release for our 3.31 stream (we skipped 3.31.0).

Update

To update to Quarkus 3.31, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.31.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.31 migration guide.

完全な変更履歴

You can get the full changelog of 3.31.2 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.31 - Full Java 25 support, Quarkus Maven packaging, Panache Next, and more!

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 28 Jan 2026 00:00:00 +0000

It has been two months since our last feature release, and we are excited to announce the availability of Quarkus 3.31!

Quarkus 3.31 comes with a LOT of new features and improvements:

Full Java 25 support
#51587 - Introduce a quarkus Maven packaging and an assorted lifecycle
#50058 - Introduce Panache Next, our next generation of Panache with improved developer experience and new features for both Hibernate ORM and Hibernate Reactive
#50519 - Upgrade to Hibernate ORM 7.2, Reactive 3.2, Search 8.2, Elasticsearch 9.2 / OpenSearch 3.3 for clients / server (dev services)
#51586 - Hibernate Spatial support
#51314 - Upgrade to Testcontainers 2
#51412 - Upgrade to JUnit 6
#50987 - Support security annotations on Jakarta Data repositories
#51188 - Support @PermissionsAllowed security annotation on REST Data Panache endpoints
#51220 - Encrypt OIDC tokens for custom TokenStateManager implementations
#51383 - Allow to configure OIDC DB token state manager column sizes for tokens
#51743 - Allow to select OIDC client for individual dynamic GraphQL clients
#51679 - Allow to assign a user and roles to a scheduled task
#51799 - Add support for OAuth 2.0 Pushed Authorization Requests to OIDC extension
#50603 - Enable headless AWT on Windows for native images
#51736 - Require Maven 3.9.0+ for Quarkus projects
#51049 - Add i18n to Dev UI

As usual, this release also includes many bug fixes, including fixes for some very old issues created in 2020, thanks to our amazing community!

We highly recommend to have a look at the migration guide as this version comes with some important changes.

Update

To update to Quarkus 3.31, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.31.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.31 migration guide.

変更点

Full support for Java 25

Quarkus 3.31 adds full support for Java 25, including Java 25 runtime images and native image builds with Mandrel.

If you create new projects with Java 25, the projects will fully target Java 25 by default.

We were hard at work to ensure compatibility and avoid as many warnings as possible when running Quarkus applications on Java 25. If you encounter any issues, including warnings that shouldn’t be there, please report them on our bug tracker.

New quarkus Maven packaging and lifecycle

A few months ago, we started working on making our builds faster (see this blog post for all the gory details). With Quarkus 3.31, we are introducing a new Maven packaging type called quarkus, designed to provide a more integrated and significantly more efficient build lifecycle.

In other words, we move away from the default Maven jar lifecycle and introduce a Quarkus-specific lifecycle optimized for Quarkus applications, avoiding the execution of goals that are unnecessary in most cases.

It is the default for newly created Quarkus projects and it can also be used for existing projects (see the migration guide for more details).

Larger applications

This "faster builds" effort is particularly beneficial for larger applications and we alleviated one of the latest bottleneck for creating VERY large applications: the number of CDI beans in the application could hit some class file limits during the build.

With Quarkus 3.31, you shouldn’t be limited by the number of CDI beans anymore.

Panache Next

If you use Hibernate ORM with Quarkus, you are probably already familiar with Hibernate ORM with Panache.

Panache Next is our next generation of Panache that brings a better developer experience and new features. While relying on the same underlying concepts as the current Panache implementation, Panache Next introduces a more intuitive API, improved type safety, and enhanced query capabilities. It also unifies the programming model between Hibernate ORM and Hibernate Reactive, stateful and stateless sessions, making it easier for developers to switch between them. Finally, it integrates seamlessly with Jakarta Data.

There would be a lot more to say but the best is to have a look at the documentation, and give it a try.

It is still experimental and we are very looking forward to your feedback.

Hibernate ORM

Quarkus 3.31 upgrades Hibernate ORM to 7.2, Hibernate Reactive to 3.2, Hibernate Search to 8.2, and the Elasticsearch/OpenSearch clients and servers to 9.2/3.3 respectively.

It also brings support for Hibernate Spatial, allowing developers to work with spatial data types and perform spatial queries in their Quarkus applications.

JUnit 6 and Testcontainers 2

We upgraded to JUnit 6 (the update is relatively straightforward) and Testcontainers 2 (which comes with a lot more breaking changes).

The -junit5 extensions have been renamed to -junit, with relocations in place to avoid breaking existing projects. Use quarkus update to get them updated automatically.

セキュリティー

What would be a Quarkus release without security improvements?

This release comes with a lot of improvements to our security extensions, including:

#50987 - Support security annotations on Jakarta Data repositories
#51188 - Support @PermissionsAllowed security annotation on REST Data Panache endpoints
#51220 - Encrypt OIDC tokens for custom TokenStateManager implementations
#51383 - Allow to configure OIDC DB token state manager column sizes for tokens
#51743 - Allow to select OIDC client for individual dynamic GraphQL clients
#51679 - Allow to assign a user and roles to a scheduled task
#51799 - Add support for OAuth 2.0 Pushed Authorization Requests to OIDC extension

Maven 3.9 required

Maven 3.9 is now required to build Quarkus applications.

Headless AWT on Windows for native images

We added support for headless AWT on Windows for native images to our AWT extension.

I18N for Dev UI

The Dev UI is now internationalized.

Contributions are welcome to improve the translations and add new languages.

完全な変更履歴

You can get the full changelog of 3.31.0.CR1, 3.31.0, and 3.31.1 on GitHub.

コントリビューター

The Quarkus community is growing and has now 1153 contributors. Many many thanks to each and everyone of them.

In particular for the 3.31 release, thanks to Ales Justin, Alexandre Dutra, Alexey Loubyansky, Andrea Boriero, Andy Damevin, Anis Da Silva Campos, Aurea Munoz, Aurélien Pupier, Bastian, Brian Setz, Bruno Baptista, cfitzw, Chihiro Ito, Chris Laprun, Christian Pieczewski, Clement Escoffier, dancer13, David M. Lloyd, Dione de Souza Silva, Evgeny Potapov, Fedor Dudinsky, Foivos Zakkak, Fouad Almalki, Francesco Nigro, Galder Zamarreño, George Gastaldi, Georgios Andrianakis, Guillaume Smet, Holly Cummins, Jakub Pietrzak, James Netherton, Jan Martiska, Jan Schatteman, Jeff Mesnil, Jens Teglhus Møller, Jiri Ondrusek, Julien Ponge, Karm Michal Babacek, Katia Aresti, Ladislav Thon, Lars, Lars Andringa, lloydmeta, Luca Molteni, Lucas, Lucas Pottersky, Lukas Lowinger, Maciej Lisowski, Marco Belladelli, Marco Sappé Griot, mariofusco, marko-bekhta, Martin Bartoš, Martin Kouba, Martin Ocenas, Martin Panzer, Matheus Cruz, matthaios.stavrou, Melloware, Michael Edgar, Michal Vavřík, Nicolo Pietro Belcastro, Olivier V, Ozan Gunalp, Phillip Krüger, Quark, Roberto Cortez, Rolf Thorup, Rolfe Dlugy-Hegwer, Rostislav Svoboda, Sanne Grinovero, Sergey Beryozkin, Severin Gehwolf, shjones, sNiXx, staillebois, Stefan Oehme, Steve Hawkins, Stéphane Épardaud, Teymur Babayev, Thomas Segismont, Thorsten Meinl, Victor Dalosto, Wei Huang, Willem Jan Glerum, xstefank, and Yoann Rodière.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.30.8 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Fri, 23 Jan 2026 00:00:00 +0000

Today, we released Quarkus 3.30.8, a new maintenance release for our 3.30 stream.

It fixes a regression impacting OpenTelemetry and MDC data propagation introduced in 3.30.7.

Update

To update to Quarkus 3.30, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.30.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.30 migration guide.

完全な変更履歴

You can get the full changelog of 3.30.8 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Retiring community UBI 8 images for Quarkus

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 21 Jan 2026 00:00:00 +0000

As you may know, Quarkus provides container images based on Red Hat Universal Base Image (UBI) both for building applications and for running them.

Since Quarkus 3.19, Quarkus is using UBI 9 as the default base image for container images. Given the oldest version we maintain in the community is 3.20 LTS, we have decided to retire the community UBI 8 images for Quarkus in March 2026.

We won’t drop the images from our community Quay repository but they won’t be updated anymore. Which means that CVE issues affecting UBI 8 won’t be fixed in the community Quarkus UBI 8 images anymore.

If you are still using UBI 8 images for building or running your Quarkus applications, we strongly recommend you to migrate to the UBI 9-based images as soon as possible. If you have a very specific need to stay on UBI 8, please reach out to us.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.30.7 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 21 Jan 2026 00:00:00 +0000

Today, we released Quarkus 3.30.7, a new maintenance release for our 3.30 stream, containing a couple additional fixes and a Vert.x micro update.

Quarkus 3.31 will be released next week. It comes with two months of work so expect many new features and improvements!

Update

To update to Quarkus 3.30, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.30.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.30 migration guide.

完全な変更履歴

You can get the full changelog of 3.30.7 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.27.2 released - LTS maintenance release

Jan Martiška (https://twitter.com/janmartiska) — Wed, 21 Jan 2026 00:00:00 +0000

Today, we released Quarkus 3.27.2, our next maintenance release for the 3.27 LTS stream.

This release contains bugfixes, documentation updates and fixes the following CVEs:

It should be a safe upgrade for anyone already using 3.27.

Update

To update to Quarkus 3.27, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update --stream=3.27

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.27.

完全な変更履歴

You can get the full changelog of 3.27.2 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.20.5 released - LTS maintenance release

Jan Martiška (https://twitter.com/janmartiska) — Wed, 21 Jan 2026 00:00:00 +0000

Today, we released Quarkus 3.20.5, our next maintenance release for the 3.20 LTS stream.

This release contains bugfixes, documentation updates and fixes the following CVEs:

It should be a safe upgrade for anyone already using 3.20.

Update

To update to Quarkus 3.20, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update --stream=3.20

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.20.

完全な変更履歴

You can get the full changelog of 3.20.5 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

A2A Java SDK 1.0.0.Alpha1 - Embracing the 1.0 Specification

Kabir Khan (https://twitter.com/kabirkhan) — Mon, 19 Jan 2026 00:00:00 +0000

I am pleased to announce the release of A2A Java SDK 1.0.0.Alpha1. This release represents a significant milestone as we align with the upcoming 1.0 version of the Agent2Agent (A2A) Protocol specification. Note that the specification itself is still being finalised, so there might be some subtle changes until the final 1.0 version.

The A2A Protocol enables standardized communication between AI agents, allowing them to discover capabilities, delegate tasks, and collaborate seamlessly. This SDK provides a robust Java implementation for building both agents and clients that participate in the A2A ecosystem.

Why 1.0 Matters

The move to version 1.0 of the A2A specification marks its transition from experimental to production-ready. As the specification matures, we’ve taken the opportunity to clean up technical debt, modernize our implementation, and establish patterns that will serve us well into the future.

This release contains breaking changes. We made the deliberate decision not to maintain backward compatibility with the 0.3.x series, as 1.0 represents the first "proper" release of the specification. This allows us to build on a solid foundation without carrying forward legacy patterns.

Major Changes

1. Specification Alignment

The SDK now implements protocol version 1.0 and aligns with the latest a2a.proto definitions. Key specification changes include:

AgentCard evolution: The AgentCard now uses a supportedInterfaces list instead of separate url, preferredTransport, and additionalInterfaces fields. This provides a cleaner, more flexible way to advertise multiple protocol bindings.
Removed kind discriminators: The 1.0 specification eliminates the kind field as a type discriminator, simplifying the protocol.
Refined error handling: Error classes have been reworked to match the 1.0 specification’s error model.

2. Modern Java: Standardized on Records

The entire spec module has been modernized to use Java records consistently. Previously, we had a mix of traditional classes and records across our domain model. Now all domain classes leverage records for immutability and conciseness, and all getters follow the same naming pattern:

// Before (0.3.x): Mix of classes and records with inconsistent patterns
public class AgentCard {  // Some were classes
    private final String name;
    public String getName() { return name; }  // JavaBean-style getters
}

public record AgentSkill(String id, String name, ...) { }  // Some were already records
// Accessor: skill.name() without 'get' prefix

// After (1.0.x): Consistent records throughout
public record AgentCard(
    String name,
    String description,
    AgentProvider provider,
    String version,
    List<AgentInterface> supportedInterfaces,
    String protocolVersion) {

    public static final String CURRENT_PROTOCOL_VERSION = "1.0";
}

public record AgentSkill(String id, String name, String description, ...) { }

// Uniform accessor pattern throughout: card.name(), skill.name()

This standardization eliminates confusion and reduces boilerplate while providing a cleaner, more maintainable API.

The A2A Java SDK has seen significant improvements in type safety and **null-safety** through progressive adoption of JSpecify annotations over the past few months. This effort demonstrates the project's commitment to code quality and preventing null pointer exceptions at compile time.

Builder Pattern with Static Factory Methods

All builders now use static factory methods instead of public constructors. This provides better encapsulation and follows modern Java best practices:

// Before (0.3.x): Public builder constructor
AgentCard card = new AgentCard.Builder()
    .name("My Agent")
    .description("Does things")
    .build();

// After (1.0.x): Static factory method
AgentCard card = AgentCard.builder()  (1)
    .name("My Agent")
    .description("Does things")
    .version("1.0.0")
    .capabilities(AgentCapabilities.builder()  (2)
        .streaming(true)
        .pushNotifications(false)
        .build())
    .defaultInputModes(List.of("text"))
    .defaultOutputModes(List.of("text"))
    .skills(List.of(
        AgentSkill.builder()  (3)
            .id("weather_query")
            .name("Weather Queries")
            .description("Get current weather")
            .build()
    ))
    .supportedInterfaces(List.of(
        new AgentInterface("JSONRPC", "http://localhost:9999")
    ))
    .protocolVersion(AgentCard.CURRENT_PROTOCOL_VERSION)
    .build();

1	`AgentCard.builder()` creates the builder - constructor is now private
2	Nested builders also use static factory methods
3	All spec classes follow this pattern consistently

Builder constructors are now private in the declaring classes, enforcing the use of the static factory method pattern throughout the SDK.

3. Protocol Buffers as Source of Truth

We’ve eliminated our dependency on Jackson and established protocol buffers (protobuf) as the authoritative source for our domain model. The architecture is straightforward:

Protobuf definitions in a2a.proto define the wire format
Java records in the spec module provide the SDK’s API
MapStruct mappers handle conversions, giving compile errors if protobuf and spec classes go out of sync
Gson handles JSON serialization for JSON-RPC transport

This provides type safety across all transports, a single source of truth for the protocol, and clean separation between wire format and API without cluttering domain classes with serialization annotations.

4. Bill of Materials (BOMs)

We’ve introduced Maven BOMs to simplify dependency management:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.github.a2asdk</groupId>
            <artifactId>a2a-java-sdk-bom</artifactId>
            <version>1.0.0.Alpha1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Three BOMs are available:

a2a-java-sdk-bom: Core SDK and client libraries
a2a-java-extras-bom: Optional extensions (JpaDatabaseTaskStore and -PushNotificationStore, replicated QueueManager, Vert.X HTTP client)
a2a-java-reference-bom: Quarkus reference implementations

This eliminates version management headaches when using multiple SDK modules, and their dependencies.

5. Enhanced API Documentation

Every class in the spec module now has comprehensive Javadoc explaining its purpose, usage, and relationship to the A2A specification. We’ve also added detailed documentation for integration points in server-common and all client modules.

6. Additional Improvements

Pagination support: The ListTasks and push notification configuration endpoints now support pagination with proper Result wrappers
Pluggable HTTP client: A new A2AHttpClient interface allows custom HTTP implementations, with a Vert.x-based implementation provided
Better validation: Enhanced input validation across all transports
TCK progress: Continuous work towards full compliance with the 1.0 Test Compatibility Kit. The TCK is also work in progress, while the specification is being finalised.

Breaking Changes Summary

If you’re migrating from 0.3.x, here are the key breaking changes:

AgentCard structure: Replace url + preferredTransport with supportedInterfaces list
Builder pattern: Use AgentCard.builder() instead of new AgentCard.Builder() - applies to all spec classes
Protocol version: Update to AgentCard.CURRENT_PROTOCOL_VERSION (now "1.0")
Field renames: supportsAuthenticatedExtendedCard → supportsExtendedAgentCard
Getter naming: Records use card.name() instead of card.getName()
Package cleanup: The io.a2a.apec package has been trimmed
Serialization: If you relied on Jackson annotations, migrate to Gson patterns

はじめに

Using Maven, add the BOM and dependencies:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.github.a2asdk</groupId>
            <artifactId>a2a-java-sdk-bom</artifactId>
            <version>1.0.0.Alpha1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>io.github.a2asdk</groupId>
        <artifactId>a2a-java-sdk-reference-jsonrpc</artifactId>
    </dependency>
</dependencies>

Creating an agent requires producing an AgentCard and an AgentExecutor. The @PublicAgentCard qualifier marks the public agent card that serves as the entry point for discovery - this is what clients retrieve when discovering your agent. You can also provide an extended agent card with additional authenticated information. Here’s a minimal example:

@ApplicationScoped
public class MyAgentCardProducer {
    @Produces @PublicAgentCard
    public AgentCard agentCard() {
        return AgentCard.builder()
            .name("Weather Agent")
            .description("Provides weather information")
            .version("1.0.0")
            .capabilities(AgentCapabilities.builder()
                .streaming(true)
                .pushNotifications(false)
                .build())
            .defaultInputModes(List.of("text"))
            .defaultOutputModes(List.of("text"))
            .skills(List.of(
                AgentSkill.builder()
                    .id("weather_query")
                    .name("Weather Queries")
                    .description("Get current weather for a location")
                    .build()
            ))
            .protocolVersion(AgentCard.CURRENT_PROTOCOL_VERSION)
            .supportedInterfaces(List.of(
                new AgentInterface("JSONRPC", "http://localhost:9999")
            ))
            .build();
    }
}

@ApplicationScoped
public class MyAgentExecutorProducer {
    @Produces
    public AgentExecutor agentExecutor() {
        return new MyAgentExecutor();
    }

    private static class MyAgentExecutor implements AgentExecutor {
        @Override
        public void execute(RequestContext context, EventQueue eventQueue) {
            TaskUpdater updater = new TaskUpdater(context, eventQueue);
            updater.submit();
            updater.startWork();

            // Your agent logic here
            String response = "Current weather: Sunny, 72°F";

            updater.addArtifact(List.of(new TextPart(response, null)));
            updater.complete();
        }
    }
}

For complete examples, see the Hello World example in the repository.

Looking Forward

This alpha release brings us significantly closer to a stable 1.0 SDK. Our focus areas for upcoming releases include:

Full compliance with the 1.0 TCK test suite
Performance optimizations based on real-world usage
Additional examples and integration guides
WildFly Feature Pack for seamless Jakarta EE integration

The A2A specification itself is still evolving toward its 1.0 release. We’re actively participating in the specification process and will continue aligning the SDK as the spec finalizes.

Get Involved

We welcome contributions, feedback, and real-world usage reports! If you’re building AI agents or want to explore multi-agent architectures, the A2A Java SDK provides a solid foundation.

Repository: https://github.com/a2aproject/a2a-java
Examples: https://github.com/a2aproject/a2a-java/tree/main/examples
Specification: https://github.com/a2aproject/A2A
Issues: https://github.com/a2aproject/a2a-java/issues

Try out 1.0.0.Alpha1 and let us know how it works for your agent use cases!

Quarkus Newsletter #64 - January

James Cobb (https://twitter.com/insectengine) — Thu, 15 Jan 2026 00:00:00 +0000

Check out this great "Why Quarkus Finally “Clicks”: The 10 Questions Java Developers Ask Most" by Markus Eisele as it’s a great field guide based on real conversations at conferences, meetups, and across The Main Thread community. Read "Quarkus Hibernate with Panache Next" by Stéphane Épardaud to learn about the new Hibernate with Panache extension to unify both Hibernate ORM with Panache and Hibernate Reactive with Panache. Want a complete hands-on tutorial for modern, data-oriented application design? Markus Eisele has you covered with "Build Event-Sourced Systems in Quarkus with Java Records and CQRS". Check out Stéphane Philippart’s blog post to learn how and why to migrate your Jekyll blog to Quarkus Roq. Read "Modern Java Meets Native Power: Image Processing with the FFM API in Quarkus" by Markus Eisele to see how Java 25 integrates with ImageMagick to unlock fast, safe, zero-JNI native workflows. Want a simple way to disable all endpoints in a Quarkus application based on a configuration property? Check out Damir Arh’s post "Disable Quarkus endpoints with a request filter" for some great instruction.

You will also see the latest Quarkus Insights episodes, top tweets/discussions and upcoming Quarkus attended events.

Check out Newsletter #64: January!

ニュースレターを受信してみませんか？ページ上のフォームを使ってニュースレターに登録してください。

Towards faster builds

Guillaume Smet (https://twitter.com/gsmet_) — Tue, 13 Jan 2026 00:00:00 +0000

When we initially released Quarkus, the industry was very much focused on microservices, and that was our primary target. However, Quarkus is also perfectly suited for large monoliths, whether you are migrating existing applications to a more modern runtime or building new ones from scratch.

Quarkus has always been able to handle large applications, but we have recently made significant improvements in this area, particularly when it comes to build times. In this post, we will walk through some of these improvements.

How the story started

Once upon a time, I came across an article comparing Spring Boot and Quarkus for building large monoliths (it’s in French, apologies to non-French speakers, but the results are largely self-explanatory).

The article compared a Spring Boot application and a Quarkus application implementing the same functionality and even included a generator to create both applications. The generated applications are simple: a few entities, some REST services, and typical CRUD endpoints. What made it really interesting was that you could easily scale up the number of entities and services to see how both frameworks handled larger applications.

I truly value this kind of feedback: it not only helps us identify areas for improvement, but also provides a reproducible way to explore them.

As expected, Quarkus excelled in memory consumption and startup time. But the build time was noticeably higher than Spring Boot’s. Again, this wasn’t a surprise. After all, Quarkus shifts more work to build time. But the difference was still significant enough to warrant a closer look.

Long story short: we investigated and we improved. A lot.

Thanks

First, I would like to thank the author of the original article, SpaceFox, for writing it and for providing such a useful generator.

As is often the case in the Quarkus world, I was not alone on this journey. I would therefore like to thank everyone who contributed through code, discussions, reviews, insights, and feedback. In alphabetical order: Tamás Cservenák, Sanne Grinovero, Martin Kouba, David Lloyd, Alexey Loubyansky, Matej Novotny, Yoann Rodière, and Ladislav Thon (and if I missed anyone, please let me know!).

This covers the core Quarkus work, but, as discussed later, several improvements were also made to the SmallRye OpenAPI project. For those contributions, I would like to thank Mike Edgar and Martin Panzer.

Our journey to faster builds

This kind of journey naturally comes with its fair share of profiling and staring at flame graphs. It’s not just about spotting the hotspots, but also about evaluating whether your changes actually move the needle (in the right direction, hopefully!). In the Java world, we’ve been lucky to have a tool as powerful as Async Profiler by our side.

As with any optimization effort, the key lies in choosing your battles wisely and carefully weighing the inevitable trade-offs.

Code optimizations

A lot of effort was invested in optimizing various parts of the build process: reducing memory allocations and optimizing algorithms and data structures were a big part of it.

This work resulted in numerous pull requests across Quarkus, Jandex, and even ByteBuddy.

Parallelization

Our build process is already massively parallelized, but we identified a few areas where this was not the case, for example, the generation of Hibernate ORM proxies. We fixed that.

Another area for improvement was the creation of large JAR archives, which is inherently slow because it involves reading and compressing a significant number of resources, making it both I/O- and CPU-intensive. Until now, we were building JARs using a ZipFileSystem, adding resources one by one in a single thread. We have since switched to using the parallel compression support provided by Commons Compress.

This change required some fairly extensive refactoring of the JAR assembly code, but it was definitely worth it.

Doing less

All the other optimizations equally benefit Gradle builds, but the following change is specific to Maven as it relates to the Maven default lifecycle.

With all these optimizations, the time spent in the various goals of the quarkus-maven-plugin was cut in half compared to our reference version, 3.25.1. That’s great… but building our sample application still took around two minutes, which is more than we would like.

It’s time to step back and look at the bigger picture.

For Quarkus applications, we build our own JARs for two main reasons:

We need to include additional resources and metadata.
We introduced custom JAR packagings designed to improve startup time.

This is the process we optimized by leveraging the parallel compression support provided by Commons Compress.

However, when using Maven, a Quarkus application is still a traditional jar Maven project. It follows the standard lifecycle for the jar packaging, which means Maven will also build a conventional JAR using the maven-jar-plugin.

Taking a step back, we actually don’t need this JAR in 99% of cases, so we should avoid building it (while still keeping the flexibility to do so when absolutely necessary).

In Quarkus 3.31, we introduced the quarkus packaging, which comes with its own lifecycle. This packaging is intended to be used only for the Quarkus application module itself. It automatically binds the goals of the quarkus-maven-plugin, resulting in less boilerplate in your pom.xml (and no changes required when new goals are added). More importantly, it does not bind the maven-jar-plugin execution, nor the maven-install-plugin, which leads to significantly faster builds for large applications, and benefits all applications overall.

For newly generated applications, this new quarkus packaging will be the default.

Once 3.31 is released, you will also be able to switch your existing applications to the new packaging by applying the following changes:

diff --git a/pom.xml b/pom.xml
index 98660b8..3c60220 100644
--- a/pom.xml
+++ b/pom.xml
@@ -5,6 +5,7 @@
     <groupId>fr.spacefox.perftests.quarkus</groupId>
     <artifactId>perftests-quarkus</artifactId>
     <version>1.0.0-SNAPSHOT</version>
+    <packaging>quarkus</packaging> (1)

     <properties>
         <compiler-plugin.version>3.14.0</compiler-plugin.version>
@@ -66,16 +67,6 @@
                 <artifactId>quarkus-maven-plugin</artifactId>
                 <version>${quarkus.platform.version}</version>
                 <extensions>true</extensions> (2)
-                <executions> (3)
-                    <execution>
-                        <goals>
-                            <goal>build</goal>
-                            <goal>generate-code</goal>
-                            <goal>generate-code-tests</goal>
-                            <goal>native-image-agent</goal>
-                        </goals>
-                    </execution>
-                </executions>
             </plugin>
             <plugin>
                 <artifactId>maven-compiler-plugin</artifactId>

1	Use the `quarkus` packaging instead of the default `jar` packaging.
2	This is important and has been present in the generated projects for quite some time. Add it if not already there.
3	Drop the goals, they will be handled automatically and we don’t want to run them twice.

To give you an idea of the impact, in our sample large application, this change alone reduced the build time from two minutes down to 37 seconds.

Follow-ups

SmallRye OpenAPI

In November 2025, I presented part of this work during the first Quarkus community call (see here for more information about our community calls).

Following this presentation, Martin Panzer, one of our regular community contributors, opened an issue in the SmallRye OpenAPI project highlighting how slow the build could be for large applications. He provided a solid reproducer, which enabled Mike Edgar to implement several improvements that significantly reduced the contribution of SmallRye OpenAPI to the overall build time.

These changes will directly benefit Quarkus build times, but since SmallRye OpenAPI is also used by other runtimes, they will positively impact the broader Java ecosystem as well.

The takeaway is simple: when you notice something odd, report it, we might be able to improve it.

The infamous ClassTooLargeException

In Quarkus, we generate a significant amount of bytecode, and for large applications you need to be careful, as scale can cause our generated bytecode to hit certain limits (for example, method size or class size limits).

The original French article mentioned hitting such a limit at a particular scale. To be fair, that scale was already quite large, but it’s still not ideal to run into an arbitrary limit just because one class happens to push you over the edge.

We recently alleviated this limitation, and Quarkus can now handle much larger applications. This improvement will also be available in Quarkus 3.31.

Java 25

Recently, we have rewritten most of our bytecode generation to use Gizmo 2, which is built on top of the Class-File API. This work is still ongoing, but key components such as ArC, our CDI implementation, are already relying on it.

To preserve compatibility with Java 17 and 21, we currently use a backport of the Class-File API, but the Class-File API is relying on some classes from the underlying JDK. Several of these classes have seen significant optimizations in Java 25, and as a result, our bytecode generation performance improves noticeably when running on Java 25.

As Quarkus 3.31 will provide full support for Java 25, we recommend using it to build your applications and take advantage of these performance improvements.

まとめ

Quarkus has always pushed the boundaries of developer experience: we introduced Dev Mode, pioneered the concept of Dev Services, and much more.

But sometimes, improving developer experience means going back to the basics: build times.

That’s exactly what we focused on here, and we hope you’ll enjoy building your Quarkus applications faster (and greener!).

And if you spot additional opportunities to improve our build process, don’t hesitate to open an issue: we’re always happy to hear new ideas.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.30.6 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 07 Jan 2026 00:00:00 +0000

Today, we released Quarkus 3.30.6, a new maintenance release for our 3.30 stream, and our first release for 2026.

Quarkus 3.31 will be released at the end of the month.

Update

To update to Quarkus 3.30, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.30.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.30 migration guide.

完全な変更履歴

You can get the full changelog of 3.30.6 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

A Better Way of Creating Dev Services

Holly Cummins (https://twitter.com/holly_cummins) — Mon, 05 Jan 2026 00:00:00 +0000

In Quarkus 3.25, a new API for creating Dev Services was introduced. This new model fixes a problem where all Dev Services for all tests would start in the JUnit discovery phase, potentially causing port conflicts, configuration cross-talk, and excessive resource usage. This issue was a side effect of the test classloading rewrite in Quarkus 3.22. As well as reducing resource consumption, we also hope the API makes it simpler for extension authors to create Dev Services, and moves some of the heavy lifting around managing discovery and container re-use to Quarkus core.

What changes for users?

No action is needed for users.

If you have test suites which use multiple profiles or test resources, you should find that you no longer see duplicate containers active at the same time. The containers should launch one after the other.

However, this depends on the extension, as each needs to be converted to the new model. The Redis, Lambda, Narayana, and Kafka extensions have been converted so far. You can track progress on conversions by following the sub-issues in #45785. As a workaround, if extensions you depend on have not yet been converted, splitting conflicting tests into separate projects should fix symptoms.

As always, if you spot issues or oddities, please let us know on zulip or raise an issue.

背景

All dev services using the old API start in the JUnit discovery phase (as of Quarkus 3.22). This is because they are started during the augmentation phase, along with bytecode manipulation and other application initialization steps. When the testing design changed, all augmentation happened at the beginning of the test run, during the JUnit discovery phase. This means all Dev Services also start at the beginning of the test run. If several test classes with different Dev Service configuration are augmented before any tests are run, multiple differently-configured Dev Services may be running at the same time.

In the new model, Dev Services are started after the augmentation but before the application’s actual launch.

What changes for extension owners?

The new Dev Services model maintains backwards compatibility with the old one, so extension owners don’t need to do anything. In fact, for the first few releases of the new model, we recommended extension owners definitely did not do anything, while the API stabilised.

Now is a good time for extensions to start moving, so they can take advantage of the more concise programming model and reduced resource usage. This will also resolve some deprecation warnings triggered by the old model. Be aware that extensions which have moved to the new API will no longer work with old versions of Quarkus. 3.25 would be the minimum possible version, and we would recommend setting 3.27 or 3.28 as the minimum version (more on that below).

Principles of the new design

Dev Services are prepped at build time, but the actual start() call happens post-build, pre-runtime
Do not use static variables in the extension processor
Dev Service creation is handled by a builder (and there are different builders for connecting to an externally-managed instance and creating a new service)
Config which is only known after the service is started can be passed in using a configProvider()

Migration checklist

Update your extension’s build file so it depends on both the quarkus-devservices runtime and quarkus-devservices-deployment modules (but see the discussion of choosing a Quarkus version for implications of this).
Provide an implementation of io.quarkus.deployment.builditem.Startable which has methods for starting and stopping the new service. For container-based services, extending GenericContainer and implementing Startable is a good pattern.
Instead of directly constructing a DevServicesResultBuildItem, switch to use the discovered() and owned() builders on DevServicesResultBuildItem
- It is not necessary to call all methods on the builder, but either for owned services, startable(), serviceName(), configProvider(), and serviceConfig() are almost always needed
Check code for anti-patterns
- Extension code should never stop or start the Dev Service
- Remove shutdown listeners; cleanup should be handled in the stop() method of the service’s Startable
- The RunningDevService type should never be used in the new model
- Remove static variables in the extension processor (such as pointers to a service instance)
- Do not try and set configuration for accessing the new service directly using system properties or other overrides; use configProvider() instead

More migration details

Get rid of static fields on the extension processor

Extension authors should not rely on static variables for cross-instance communication. They should not assume that the invocation order of processors will be the same as the run order of applications.

The extension writing guide says “State should only be communicated between build steps by way of build items, even if the steps are on the same class.” However, almost every Dev Service implementation broke this rule, and used a static field to track previously-created services.

A good heuristic when migrating to the new model is that all static fields should go away. For example, remove all fields like these ones:

private static volatile RunningDevService devService;
private static volatile MyDevServicesConfig capturedDevServicesConfiguration;
private static volatile boolean first = true;

Deciding whether to re-use or replace a service is now handled centrally, based on a diff of the configuration.

Get rid of shutdown logic

Because service lifecycle is handled centrally, any shutdown listeners or other logic for stopping services should also be removed.

Remove any references to `RunningDevService`

Because the processor does not handle starting the service, it should never return a RunningDevService.

Use the builder

Instead of direct construction, use the new builder API. Choose owned() for services which are to be created, or discovered() to register externally-managed services which have been discovered.

例えば

    DevServicesResultBuildItem = DevServicesResultBuildItem.owned()
                    .feature(MY_FEATURE_NAME)
                    .serviceName(name)
                    .serviceConfig(myConfig)
                    .startable(() -> new MyContainer(
                            myImageName,
                            myConfig.port(),
                            useSharedNetwork)
                            .withEnv(myConfig.containerEnv())
                     .configProvider(
                            Map.of(someProp, s -> s.getConnectionInfo()))
                    .build());

Eligibility for re-use

How does the central lifecycle management decide whether a service can be re-used? This is based on 'sameness keys' (the config objects) passed in to the builder to use as the basis for the comparison.

The key method is .serviceConfig(myConfig). The current config is compared reflectively to the config of running services each restart.

The `Startable`

In order to support lazy starting, pass an implementation of Startable to the builder. (In case it’s not obvious, do not call start() on your Startable. The Quarkus infrastructure will start your service at the appropriate time.) (In case it’s not obvious, do not call start() on your Startable. The Quarkus infrastructure will start your service at the appropriate time.)

For container-based services, it’s usually convenient to extend GenericContainer. In that case, there’s not even any need to implement start(). Most Dev Services implementations already provide a subclass of GenericContainer, so the diff is just to add implements Startable and then add a close() method. The close method can delegate to the superclass.

例えば

private static class MyContainer extends GenericContainer<MyContainer> implements Startable {

        private final OptionalInt fixedExposedPort;

        private final String hostName;

        public MyContainer(String imageName, OptionalInt fixedExposedPort) {
            super(imageName);
            this.fixedExposedPort = fixedExposedPort;

            this.hostName =  ...

        }

        @Override
        protected void configure() {
            super.configure();

            if (fixedExposedPort.isPresent()) {
                addFixedExposedPort(fixedExposedPort.getAsInt(), DEFAULT_PORT);
            } else {
                addExposedPort(DEFAULT_PORT);
            }
        }

        public int getPort() {
            if (fixedExposedPort.isPresent()) {
                return fixedExposedPort.getAsInt();
            }
            return super.getFirstMappedPort();
        }

        // This looks strange, but is needed to satisfy the interface
        @Override
        public void close() {
            super.close();
        }

        @Override
        public String getConnectionInfo() {
            return getHost() + ":" + getPort();
        }

Dependency changes and setting a minimum Quarkus version

This bit is a bit awkward, unfortunately! In Quarkus 3.28, a new devservices runtime module was introduced. Most extensions have both a deployment and a runtime module, but historically, Dev Services only had a deployment module. The associated runtime classes lived in other modules. A runtime module was added in 3.28. Because it was a potentially disruptive change, it was done post-LTS. That seemed like a good idea, but it had some unexpected consequences. The introduction of the new module was done in a way which preserved backwards compatibility, but not forward compatibility. That means extensions built against 3.27 will work with the 3.27 LTS, but not 3.28 or later versions. Extensions built with 3.28 will work with 3.27, and also 3.28 and later versions.

For this reason, you should either create branches for 3.27 and 3.28+ versions of the extension, or just build against 3.28. If you build against 3.28, you will need to manually set the minimum Quarkus version in the extension metadata, so that the Quarkus tooling recognises the extension as compatible with 3.27.

  requires-quarkus-core: "[3.27,)"

If you do decide to build against 3.28, add the following to the pom.xml of your runtime module:

<dependency>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-devservices</artifactId>
</dependency>

FAQs

How can I have a build step do something after a Dev Service is started?

This isn’t possible, because a dev service would never be started in the build phase. However, the postStartHook on the builder allows you to take actions once the dev service is started. To pass configuration to the application, you can use recorders.

How can I publish links to my service in the Dev UI?

If your service has an admin console, it’s a nice pattern to publish a link to it in the Dev UI. With the old Dev Services model, you might customise your extensions’s card with code something like this:

   @BuildStep(onlyIf = IsDevelopment.class)
   public CardPageBuildItem pages(List<SomeRelevantBuildItem> containers) {
      CardPageBuildItem cardPageBuildItem = new CardPageBuildItem();

      for (SomeRelevantBuildItem container : containers) {
         cardPageBuildItem.addPage(Page.externalPageBuilder("My Extension Name")
               .url(container.getTheUrl())
               .staticLabel(container.label());
      }

      return cardPageBuildItem;
   }

This will no longer work, because the url isn’t known at build time. Instead, replace the url method with dynamicUrlJsonRPCMethodName, passing in an RPC method name.

     .dynamicUrlJsonRPCMethodName("getMyUrl")

From 3.32, you can also pass through parameters on the method call. For example,

     .dynamicUrlJsonRPCMethodName("getMyUrl", Map.of("name", "service-name", "configKey", "some-key");

Add a build step to register the providing class:

    @BuildStep(onlyIf = IsLocalDevelopment.class)
    public JsonRPCProvidersBuildItem createJsonRPCService() {
     return new JsonRPCProvidersBuildItem(MyJsonRPCService.class, BuiltinScope.SINGLETON.getName());
    }

In your extension’s runtime module, create a MyJsonRPCService class with a getMyUrl method.

例

Sometimes it’s easier to see what needs to be done in a diff.

For an example using a dev service which isn’t container-based, see the Lambda conversion. For a more complex conversion which uses compose, reuses existing external containers, and does post-start configuration, see just the KafkaDevServicesProcessor part of the Kafka conversion.

The working group for Dev Services lifecycle is still underway, and welcomes contributions.

Quarkus 3.30.5 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 24 Dec 2025 00:00:00 +0000

Today, we released Quarkus 3.30.5, a new maintenance release for our 3.30 stream, and our last release for 2025.

See you all next year!

Update

To update to Quarkus 3.30, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.30.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.30 migration guide.

完全な変更履歴

You can get the full changelog of 3.30.5 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus Hibernate with Panache Next

Stéphane Épardaud (https://twitter.com/UnFroMage) — Wed, 24 Dec 2025 00:00:00 +0000

Introducing a new version of Panache

…which was never called Panache, by the way, it was called Hibernate ORM with Panache, or Hibernate Reactive with Panache, and this new version, is a new module, designed to unify both, and is currently called Hibernate with Panache (although the name could change).

Anyway, first a disclaimer: this is a new extension, which is experimental, which means everything about it can (and probably will) change: the extension name, the package names, the class names and even the API. We are releasing it because we feel it’s in a good shape to be tested and discussed by the community, and we hope to get better feedback before we commit to anything like names or API.

Please report feedback either on Zulip or via GitHub issues.

What was wrong with the old Panache APIs?

Mostly it’s fine, but it has a few drawbacks that are definitely annoying and dated:

We have two competing and incompatible APIs depending on whether we want to use blocking or non-blocking database drivers. The recent support of mixing Hibernate ORM and Hibernate Reactive in Quarkus means people no longer want to be blocked having to choose which entity type to extend, between the blocking PanacheEntity and its non-blocking counterpart.
Both Hibernate ORM with Panache and its Hibernate Reactive counterpart only support managed entities, and we want to add support for stateless entities (using StatelessSession), but we cannot do that with the current Panache API.
We want to add support for Jakarta Data, which allows defining type-safe queries using annotations, which are checked at build time, but the current active record version of Panache entities does not easily support this.
We currently have a split between active record and repository modes of operations, which is not satisfactory, and can be confusing to new users.
The static methods of active record entities have a hole in their types which require they be either assigned to known types (not var) or have their type arguments explicitly specified.
Method pointers cannot be used on the static methods of active record entities, causing confusion.

I could spend a long time explaining each of these issues, and the many things we experimented on to fix them, but you’re probably more interested in what we came up with.

So, what’s this new API?

It’s a new Quarkus extension, and it lets you specify your entity in a way which allows you to use it using a blocking JDBC driver, or a Reactive driver, as a managed entity, or as a stateless entity, with type-safe queries, or non-type-safe queries. It’s very flexible and it’s still clearly a continuation of the old Panache APIs, with a dash of Jakarta Data and all mixed in a way that we hope you will like.

The documentation has a lot of information as to how to set it up, and all the options, so I will focus on some bite-sized samples for this blog post. Here’s your first entity with type-safe queries:

@Entity
public class Cat extends PanacheEntity {
    public String name;
    public LocalDate birth;
    public Breed breed;

    public enum Breed {
        CUTE, HAIRLESS;
    }

    public interface Repo extends PanacheRepository<Cat> {
        @Find
        Cat findByName(String name);

        @HQL("where breed = CUTE")
        List<Cat> findCute();

        @HQL("delete from Cat where name = :name")
        long deleteByName(String name);

        @HQL("delete from Cat where breed = HAIRLESS")
        long deleteHairless();
    }
}

Here’s what you can notice right away:

Your entity extends PanacheEntity (a familiar type, but in a new package), which means: by default it’s blocking and managed.
Its operations are defined in a repository that is conveniently nested in the entity. No more mixing instance entity methods and static methods, and yet you retain the close proximity of these operations.
You can define type-safe operations with @Find and @HQL
You still have all the Panache type-unsafe operations in the PanacheRepository supertype.

You could use it like this:

    @Inject
    Cat.Repo repo;

    @Transactional
    public void method() {
        Cat cat = new Cat();
        cat.name = "Lucky";
        cat.birth = LocalDate.of(2015, 01, 12);
        cat.breed = Cat.Breed.CUTE;

        // Persist the cat
        cat.persist();

        // Make a change, no need to update it
        cat.name = "Luckynou";

        // Find our cat
        cat = repo.findByName("Luckynou");

        // Find cute cats
        List<Cat> cuteCats = repo.findCute();

        // Delete our cat
        cat.delete();

        // Delete queries
        repo.deleteByName("Lucky");
        repo.deleteHairless();
    }

But if you find injecting the repository disruptive, you can also access it using the generated metamodel accessor Cat_.repo(), which is super handy for completion and API discovery.

Here’s where it gets better

Want a reactive version of your entity for stateless sessions?

@Entity
public class Cat extends WithId.AutoLong implements PanacheEntity.Reactive.Stateless {
    public String name;
    public LocalDate birth;
    public Breed breed;

    public enum Breed {
        CUTE, HAIRLESS;
    }

    public interface Repo extends PanacheRepository.Reactive.Stateless<Cat, Long> {
        @Find
        Uni<Cat> findByName(String name);

        @HQL("where breed = CUTE")
        Uni<List<Cat>> findCute();

        @HQL("delete from Cat where name = :name")
        Uni<Integer> deleteByName(String name);

        @HQL("delete from Cat where breed = HAIRLESS")
        Uni<Integer> deleteHairless();
    }
}

It’s a bit longer, at the moment, but bear with us. Here’s the run-down:

You extend WithId.AutoLong if you want a generated Long identifier.
You implement PanacheEntity.Reactive.Stateless to get reactive stateless operations by default.
Your repository implements PanacheRepository.Reactive.Stateless to get reactive stateless operations by default.
Your queries return Uni for non-blocking operation.

Otherwise, it’s the same API. Pick which mode of operation you want your entities to be based on by default. Mix and match modes for different entities if you want.

Here’s where it gets really better

Let’s say you declared your entity to be blocking and managed, but you want to also access it for a reactive and stateless part of your API.

You can always access every mode of operation on your entity or repository using supertype methods:

    // By default, the Cat is blocking and managed
    @Transactional
    public void blockingManagedMethod() {
        Cat cat = new Cat();
        cat.name = "Lucky";
        cat.birth = LocalDate.of(2015, 01, 12);
        cat.breed = Cat.Breed.CUTE;

        // Persist the cat
        cat.persist();

        // Make a change, no need to update it
        cat.name = "Luckynou";
    }

    // But we can always call statelessReactive() and use reactive and stateless operations
    @WithTransaction
    public Uni<Void> reactiveStatelessMethod(Long catId) {
        Cat cat = new Cat();
        cat.name = "Lucky";
        cat.birth = LocalDate.of(2015, 01, 12);
        cat.breed = Cat.Breed.CUTE;

        // Insert the cat
        return cat.statelessReactive().insert()
                .chain(() -> {
                    // Make a change, we need to update it
                    cat.name = "Luckynou";
                    return cat.statelessReactive().update();
                });

    }
}

You can even define multiple repositories for your different modes of operations:

@Entity
public class Cat extends PanacheEntity {
    public String name;
    public LocalDate birth;
    public Breed breed;

    public enum Breed {
        CUTE, HAIRLESS;
    }

    public interface Repo extends PanacheRepository<Cat> {
        @Find
        Cat findByName(String name);
    }

    public interface TheOtherRepo extends PanacheRepository.Reactive.Stateless<Cat, Long> {
        @Find
        Uni<Cat> findByName(String name);
    }
}

Merry Christmas

Just in time for the holidays, we’re merging this to main so it will be in a release near you very soon.

Give it a try, read the documentation, and give us feedback either on Zulip or via GitHub issues.

Quarkus 3.30.4 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 17 Dec 2025 00:00:00 +0000

Today, we released Quarkus 3.30.4, a new maintenance release for our 3.30 stream.

Update

To update to Quarkus 3.30, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.30.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.30 migration guide.

完全な変更履歴

You can get the full changelog of 3.30.4 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus feature flags

Martin Kouba (https://twitter.com/martunek) — Mon, 15 Dec 2025 00:00:00 +0000

Feature flags are a proven and popular technique. In essence, a feature flag makes it possible to turn on-off and/or configure a specific functionality in your application. It is also referred to as toggles or switches. There are many types of feature flags. You may have heard of a "killer switch" that simply disables a problematic feature instantly. Feature flags can be used to implement "gradual rollout" to deliver new features gradually to small groups of users (aka beta testers). Permission flags are used to control access for different users. And so on. However, that’s not the subject of this blogpost. We would like to introduce Quarkus Feature Flags - a Quarkiverse project that aims to provide a lightweight and extensible feature flags Quarkus extension.

More specifically, it provides:

A blocking/non-blocking API to access feature flags.
A non-blocking SPI to provide flags and externalize the computation of a flag value.
Several built-in flag providers:
Quarkus config can be used to define feature flags,
An in-memory flag repository which is useful for testing and dynamic registration of flags.
Hibernate ORM module, where feature flags are mapped from an annotated entity and are automatically loaded from the database.
Security module, so that it’s possible to evaluate flags based on the current SecurityIdentity.
Qute module, so that it’s possible to use the flags directly in templates.
CRON module with a flag evaluator that matches a specific CRON expression.

Note that the goal of this extension is not to replace robust solutions such as OpenFeature and Unleash. Instead, we would like to offer a flexible option that integrates well with other parts of the Quarkus ecosystem.

Flag

In this extension, a feature flag is represented by the io.quarkiverse.flags.Flag interface. It refers to a specific feature with a string identifier and provides several convenient methods to compute the current value. The value of a feature flag can be represented as boolean, string or integer. There can be only one flag for a given feature at a given time. A flag can also expose metadata which that can be leveraged in the SPI.

Simple example

Let’s start simple. We will create a flag for a feature called my-feature-alpha in the application.properties file.

quarkus.flags.runtime."my-feature-alpha".value=true (1)

1	Define a runtime flag for feature `my-feature-alpha` with initial value `true`.

A runtime feature flag can be overriden at runtime, e.g. using a system property or an environment variable. You can also define a flag fixed at build time, i.e. quarkus.flags.build."my-feature-alpha".value=true. However, its values cannot be modified at runtime.

The io.quarkiverse.flags.Flags interface represents the central point to access feature flags. The container registers a CDI bean that implements Flags automatically. Therefore, we will simply inject Flags and use one of its convenient methods.

package org.example;

import io.quarkiverse.flags.Flags;
import jakarta.inject.Inject;

@ApplicanScoped
public class MyService {

    @Inject
    Flags flags;

    void call() {
        if (flags.isEnabled("my-feature-alpha")) {
            // This business logic is executed only if "my-feature-alpha" value evaluates to true
        }
    }
}

You can also access the flag in your UI built with Qute:

<!DOCTYPE html>
<html>
<head>
   <title>Flags</title>
</head>
<body>
   <h1>Hello - Quarkus Club 2025</h1>
   {#if flag:enabled('my-feature-alpha')} (1)
   <p>Feature alpha is enabled!
   {/if}
</body>
</html>

1	The `flag:` namespace provides other useful properties and methods.

If you want to use the Qute integration in your application then you’ll need to add the io.quarkiverse.flags:quarkus-flags-qute extension to your build file first.

Flag providers

So far we defined the flag in the Quarkus config. This is not very flexible. Let’s try some other built-in flag providers. We can use the io.quarkiverse.flags.InMemoryFlagProvider - an in-memory repository that can be useful for testing and dynamic registration.

import io.quarkiverse.flags.BooleanValue;
import io.quarkiverse.flags.Flag;
import io.quarkiverse.flags.InMemoryFlagProvider;
import io.quarkus.runtime.Startup;
import jakarta.inject.Inject;

@ApplicationScoped
public class MyInitService {

   AtomicBoolean alpha = new AtomicBoolean();

   @Inject
   InMemoryFlagProvider provider; (1)

   @Startup (2)
   void addFlags() {
      provider.addFlag(Flag.builder("my-feature-alpha") (3)
            .setCompute(ctx -> BooleanValue.from(alpha.get())) (4)
            .build());
   }
}

1	Inject `InMemoryFlagProvider` to add/remove flags.
2	This method is automatically executed at application startup.
3	The `InMemoryFlagProvider` has higher priority and overrides the flag provided in config.
4	The current value of `my-feature-alpha` is calculated from `MyInitService#alpha`.

This way we can control the current value of my-feature-alpha easily. However, in real use cases we will probably need to persist the feature flags in an external system.

The quarkus-flags-hibernate-orm extension provides integration with Hibernate ORM. It discovers all JPA entities annotated with @io.quarkiverse.flags.hibernate.common.FlagDefinition and generates a flag provider automatically. The generated provider simply loads all flags from the database. A mapping looks like:

import jakarta.persistence.Entity;

import io.quarkiverse.flags.hibernate.common.FlagDefinition; import io.quarkiverse.flags.hibernate.common.FlagFeature; import io.quarkiverse.flags.hibernate.common.FlagValue; import io.quarkus.hibernate.orm.panache.PanacheEntity;

@FlagDefinition <1> @Entity public class MyFlag extends PanacheEntity {

    @FlagFeature (2)
    public String feature;

    @FlagValue (3)
    public String value;

}

1	Marks a flag definition entity.
2	Defines the feature name of a feature flag.
3	Defines the value of a feature flag.

The feature flags are collected at runtime. More specifically, the extension injects all CDI beans that implement io.quarkiverse.flags.spi.FlagProvider and calls the FlagProvider#getFlags() method. You can easily implement your own provider.

Flag evaluators

In real applications, you will very likely need some dynamic evaluation logic based on some application state, such as the current user or current time. There is the io.quarkiverse.flags.spi.FlagEvaluator SPI which makes it possible to externalize the computation of the current value of a feature flag. Flag evaluators must be CDI beans. By default, a flag can reference one FlagEvaluator in its metadata with a key evaluator. This evaluator is automatically used to compute the current value for any flag produced by means of Flag.Builder (i.e. created by Flag#builder(String)). There are also several built-in evaluators available.

Current time

The io.quarkiverse.flags.TimeSpanFlagEvaluator evaluates a flag based on the current date-time obtained from the system clock in the default time-zone. The current time must be after the start-time (exclusive) and before the end-time (exclusive).

quarkus.flags.runtime."my-feature-alpha".meta.evaluator=quarkus.time-span <1> quarkus.flags.runtime."my-feature-alpha".meta.start-time=2001-01-01T10:15:30+01:00[Europe/Prague] (2) (3)

1	Assign the evaluator to the flag. Note that we do not specify the initial value for `my-feature-alpha` - it is `true` by default.
2	The current date-time must be after the specified `start-time`. The `java.time.format.DateTimeFormatter.ISO_ZONED_DATE_TIME` is used to parse the `start-time` value.
3	We do not specify the `end-time` metadata value, so there is no upper bound for the time inverval.

Current user

The SecurityIdentityFlagEvaluator from the quarkus-flags-security extension can be used to compute the current value of a feature flag based on the current SecurityIdentity. A typical feature flag configuration looks like:

quarkus.flags.runtime."my-feature-alpha".meta.evaluator=quarkus.security.identity <1> quarkus.flags.runtime."my-feature-alpha".meta.authenticated=true <2> quarkus.flags.runtime."my-feature-alpha".meta.roles-allowed=foo,bar (3)

1	Assign the evaluator to the flag. Note that we do not specify the initial value for `my-feature-alpha` - it is `true` by default.
2	The current user must be authenticated.
3	The current user must have one of the defined roles.

The UsernameRolloutFlagEvaluator, on the other hand, is an evaluator using a simple percentage-based rollout strategy, based on a consistent numerical representation of the current user name. It can be used to implement gradual rollout. A typical feature flag configuration may look like:

quarkus.flags.runtime."my-feature-alpha".meta.evaluator=quarkus.security.username-rollout <1> quarkus.flags.runtime."my-feature-alpha".meta.rollout-percentage=20 (2)

1	Assign the evaluator to the flag. Note that we do not specify the initial value for `my-feature-alpha` - it is `true` by default.
2	Enable the flag for the given percentage of users.

CRON

The quarkus-flags-cron extension provides the CronFlagEvaluator that can be used to compute the current value of a feature flag based on the current date-time obtained from the system clock in the default time-zone and the configured CRON expression. A typical feature flag configuration may look like:

quarkus.flags.runtime."my-feature-alpha".meta.evaluator=quarkus.cron <1> quarkus.flags.runtime."my-feature-alpha".meta.authenticated=* * * * mon (2)

1	Assign the evaluator to the flag. Note that we do not specify the initial value for `my-feature-alpha` - it is `true` by default.
2	The current date-time must match the given CRON expression. In this particular case, the flag will be enabled every Monday.

By default, the Unix/crontab syntax is used. However, it is also possible to use the syntax from Cron4j, Quartz and Spring. For more information, see the documentation.

The case for multiple evaluators

Sometimes it might be useful to combine several evaluators to compute the value of a flag. The core extension provides io.quarkiverse.flags.CompositeFlagEvaluator that evaluates a flag with the specified sub-evaluators.

quarkus.flags.runtime."my-feature-alpha".meta.evaluator=quarkus.composite <1> quarkus.flags.runtime."my-feature-alpha".meta.sub-evaluators=quarkus.time-span, quarkus.security.identity <2> quarkus.flags.runtime."my-feature-alpha".meta.start-time=2026-01-01T12:00:00+01:00[Europe/Prague] <3> quarkus.flags.runtime."my-feature-alpha".meta.roles-allowed=admin (4)

1	Assign the evaluator to the flag. Note that we do not specify the initial value for `my-feature-alpha` - it is `true` by default.
2	The value of `sub-evaluators` represents a comma-separated list of sub-evaluator identifiers. They are executed in the specified order. In this particular case, the `TimeSpanFlagEvaluator` is executed first and then the `SecurityIdentityFlagEvaluator`.
3	The current date-time must be after the specified start-time.
4	The current user must have the role `admin`.

Extensibility

Flag providers and flag evaluators are CDI beans. So all you have to do is add a bean that implements FlagProvider or FlagEvaluator in your application. You can use CDI interceptors and even decorate these components.

まとめ

Quarkus Feature Flags is a lightweight and extensible extension that can help you build more flexible applications. Feedback, feature requests and contributions are welcome. Feel free to create questions and issues on GitHub repository: https://github.com/quarkiverse/quarkus-flags/issues.

Quarkus Newsletter #63 - December

James Cobb (https://twitter.com/insectengine) — Thu, 11 Dec 2025 00:00:00 +0000

Check out "Java Meets the Future: How Quarkus Seamlessly Combines Architecture, Performance, and Cloud-Native" by Holger Tiemeyer to see how Quarkus impressively demonstrates that even an aging ecosystem like Java can always be reinvented to meet the demands of the next technological era. Learn how to build Quarkus application images using Cloud Native Buildpacks and OpenShift Builds with Piotr Minkowski’s article; "Quarkus with Buildpacks and OpenShift Builds". Learn how to generate, extend, and optimize a Quarkus actuator-style endpoint with build-time processing, runtime beans, and native support by reading "How to Build a Custom Quarkus Actuator Extension: A Complete Java Developer’s Guide" by Markus Eisele. Did you know about Roq? A powerful new tool that combines Java and Quarkus. Ok, prep a warm drink and put on some soft music and let’s find out why Roq is so cool with the comfort of Quarkus Dev Mode and all its eco-system. Bonus: a touch of TailwindCss to make it look great! Learn more by reading Andy Damevin’s article "Discover Roq, the Quarkus Way for Static Site Generation in Java".

You will also see the latest Quarkus Insights episodes, top tweets/discussions and upcoming Quarkus attended events.

Check out Newsletter #63: December!

ニュースレターを受信してみませんか？ページ上のフォームを使ってニュースレターに登録してください。

Quarkus 3.30.3 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 10 Dec 2025 00:00:00 +0000

Today, we released Quarkus 3.30.3, a new maintenance release for our 3.30 stream.

Update

To update to Quarkus 3.30, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.30.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.30 migration guide.

完全な変更履歴

You can get the full changelog of 3.30.3 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.30.2 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 03 Dec 2025 00:00:00 +0000

Today, we released Quarkus 3.30.2, a new maintenance release for our 3.30 stream.

Update

To update to Quarkus 3.30, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.30.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.30 migration guide.

完全な変更履歴

You can get the full changelog of 3.30.2 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus: A Runtime and Framework for Cloud-Native Java

Michal Mickey Maléř (https://twitter.com/mickeymaler) — Thu, 27 Nov 2025 00:00:00 +0000

Public clouds such as AWS, Microsoft Azure, and Google Cloud, and platforms like Red Hat OpenShift, favor services that start fast and stay lean. Quarkus is engineered for exactly that. Build time processing reduces runtime overhead and results in rapid startup, a small memory footprint, and frictionless deployment across Kubernetes, OpenShift, serverless, and managed container services in any cloud. If your Java services need to start in milliseconds, run dense on shared nodes, and still feel great to build, Quarkus was made for that job.

Quarkus is a Java runtime that seamlessly integrates popular frameworks and libraries, shaping both the structure of modern applications and the developer experience behind them. In this post, “runtime” means the full execution stack in production: JVM or native, plus Quarkus and the integrated frameworks.

Quarkus itself can also work as a framework, as it constitutes a higher-level layer that provides structure and APIs.

Why Quarkus stands out?

In modern software development, runtimes and frameworks form the foundation of productivity and consistency. Frameworks promote uniformity, simplify infrastructure, and enable automation at scale.

Quarkus is a cloud-native Java runtime that integrates multiple frameworks and optimizes them for fast startup, low memory use, and smooth deployment across any cloud. It runs well on Kubernetes and Red Hat OpenShift, and it also integrates with native cloud services, from compute platforms such as AWS EC2 and Google Cloud Run to serverless offerings and managed container platforms.

Then, during development, Quarkus live reload provides instant feedback by applying code changes without a rebuild or restart. This shortens the inner loop and helps teams iterate faster than traditional redeploy cycles.

But beyond speed and live reload, Quarkus integrates established Java specifications such as CDI-Lite, JAX-RS, and JPA, with implementations provided by Arc (CDI-Lite), RESTEasy (JAX-RS), and Hibernate ORM (JPA). It also enforces its own conventions, drives behavior with annotations, and defines how applications are structured.

In this sense, Quarkus is a development framework and runtime for cloud-native Java applications. It adheres to industry standards and offers compatibility with technologies such as Spring, Apache Kafka, and Apache Camel to support familiar, flexible development models.

Quarkus as a versatile framework

Beyond staple traits of modern frameworks, Quarkus introduces two platform-defining features: buildtime optimization and deep extensibility.

Buildtime optimization: Quarkus shifts work from runtime to build time wherever possible. This approach reduces startup overhead and memory usage, resulting in a lean, fast, and efficient application tailored for production.

Figure 1. Quarkus performs at build time what traditional frameworks do at runtime: reading configuration files, scanning annotations, and building a model of the application.

Figure 2. Thanks to buildtime initialization, the resulting application starts faster and consumes less memory.

Figure 3. All the benefits of buildtime initialization also apply when compiling to a native binary.
Extensibility: Quarkus exposes extension points for everything from startup hooks to request filters. Over 800 extensions allow seamless integration with modern technologies such as Kafka, OpenTelemetry, and OpenID Connect.

These extensions integrate with Quarkus and participate in its buildtime and runtime lifecycle, making them first-class components of Quarkus.

Simplified developer experience

Frameworks succeed when they reduce complexity without sacrificing flexibility. Quarkus does exactly that:

Preconfigures popular libraries with sensible defaults.
Offers unified configuration and developer tooling.
Provides instant feedback with live reload and continuous testing.
Dev Services for automatic provisioning of databases, brokers, and other services in dev mode.
Continuous testing to run tests in the background and surface results immediately.

This makes Quarkus both powerful and approachable.

You can start with a simple REST endpoint and scale it into a production-grade service without changing your development model.

Figure 4. Frictionless developer experience: Vastly improved development feedback loop, unified approach to producing different package types, and using proven APIs that Java developers already know.

These features give developers structure, sensible defaults, and clear conventions during development, and they deliver fast startup, low memory use, and operational consistency in production.

Performance that matters

Teams optimize for different goals, such as startup latency, sustained throughput, memory footprint, elasticity, and cost. Quarkus addresses these needs by shifting work from run time to build time, keeping one development model across JVM and native, and exposing production signals such as health checks, metrics, and tracing.

Start with JVM mode for most services. On the JVM, Quarkus often starts faster and uses less memory than traditional JVM-based runtimes because it performs more work at build time. Just-in-time compilation raises steady-state throughput, scales well across cores, and offers mature garbage collectors and tuning options. The JVM also provides rich observability and diagnostics, which help you understand and tune live systems.

Use native mode when startup latency and memory footprint are strict constraints. Native executables start in milliseconds and can use less memory, which supports scale-to-zero workflows and lowers idle costs on small instances. Trade-offs include lower peak throughput, limited multi-core scaling, a single-threaded garbage collector in current native images, longer build times, and a slower inner loop for developers.

If your system needs both profiles, split by workload. Run bursty or event-driven endpoints in native mode, and run long-lived high-throughput services on the JVM.

Observability note. JVM mode exposes richer diagnostics and metrics, including GC, heap, and thread telemetry, JFR, and profiler support, which makes issue triage and performance tuning easier. Native mode still exports application-level metrics and traces with Micrometer and OpenTelemetry, but it offers fewer VM-level signals.

Always measure your workload:

For native, reduce reflection and dynamic class loading, trim resources, and consider profile-guided optimizations (PGO) where supported. PGO is not available in Mandrel and currently requires an Oracle GraalVM distribution that provides PGO.
For the JVM, choose a garbage collector that matches your latency and heap goals, budget for warmup, and test steady-state throughput under realistic load.

Taken together, these in production choices provide measurable wins:

セキュリティー

Quarkus uses a standards-first composable security model. You enable what you need and configure it for your environment:

Transport: Enable HTTPS in the application by configuring TLS.
Authentication: Choose Basic, form-based, mTLS, OpenID Connect (OIDC), or WebAuthN.
Authorization: Enforce RBAC on web endpoints with @RolesAllowed, @DenyAll, and @PermitAll.

This lets you apply the right security controls for each deployment.

Observability and control surfaces

Common control surfaces, such as metrics, logging, tracing, and configuration, are essential for site reliability engineers (SREs) and platform teams.

Quarkus exposes:

Unified logging with quarkus-logging.
Centralized logging with OpenTelemetry (OTLP logs) with OpenTelemetry.
Metrics and tracing with Micrometer and OpenTelemetry.
Unified configuration of all the application’s aspects by using application.properties or environment variables.

This standardization enables automation and scalable monitoring.

Modular and production-ready

Following a lean-core, modular-at-the-edge approach, Quarkus delivers:

A minimal core for fast startup.
Pluggable extensions for authentication, tracing, messaging, and more.
Built-in production primitives, including health checks, readiness and liveness probes, and graceful shutdown.
Fault tolerance with standard annotations, for example, retries, circuit breakers, bulkheads, and timeouts.

Whether you are building a prototype or deploying to OpenShift, Quarkus adapts. This modularity spans both the framework-level APIs developers work with and the runtime behaviors that execute beneath them.

Because Quarkus modularity is declarative and unified across extensions, it supports a platform-like developer experience without the rigidity of traditional frameworks.

Building your stack with Quarkus

We will explore this topic in depth in part 3 of this series. For now, here is how Quarkus fits into the picture.

Frameworks can serve as a foundation for creating higher-level abstractions.

Quarkus fits this model by enabling teams to build customized stacks and internal frameworks on top of it.

Unlike many traditional frameworks, Quarkus provides a unified extension architecture that supports deep customization. Organizations can tailor Quarkus to fit specific domains, technologies, or compliance needs. This enables the creation of organization-specific developer experiences, including internal stacks built on a unified Quarkus extension architecture.

By encouraging consistency, offering buildtime integration, and exposing clean extension points, Quarkus supports the creation of opinionated, scalable internal frameworks without forking or reinventing the core.

By packaging Quarkus extensions, curated defaults, and service templates into an internal Quarkus stack, teams focus on business logic. At the same time, your framework layer standardizes infrastructure, security, and operational integrations across services. This has been proven by Logicdrop, who refactored their entire Spring Boot stack with Quarkus, reducing container size by ~75%, achieving sub-second startup times, and significantly improving developer productivity.

For more information, see the Logicdrop customer story and their GitLab automation write-up.

まとめ

Quarkus unifies the strengths of a development framework and a runtime. As a framework, it provides structure, conventions, and a cohesive developer experience. As a runtime, it delivers fast startup, low memory use, and operational consistency in the cloud. This dual role helps teams standardize practices, reduce costs, and ship resilient cloud-native services.

Quarkus is built in the open under the Apache License 2.0, governed with the Commonhaus model, and developed end-to-end on GitHub. Beyond the core project, the ecosystem includes the Quarkiverse Hub, a community-run collection of Quarkus extensions and related projects. The Quarkiverse Hub provides repository hosting with build, CI, and release publishing, so features land as versioned, testable modules you can adopt, fork, or extend.

So, that’s all for now, thank you for reading, and let’s meet again in the third article of this series, which will cover building your own stack with Quarkus.

For a closer look at how Quarkus makes Java cloud-native, see the introductory blog post.

Quarkus 3.30 - JsonView on REST Client, Hibernate Validator 9.1, CLI decrypt command, and more

Guillaume Smet (https://twitter.com/gsmet_) — Wed, 26 Nov 2025 00:00:00 +0000

Today, we released Quarkus 3.30.

Quarkus 3.30 introduces the following notable changes:

#51043 - Introduce support for @JsonView on the REST Client
#50196 - Update to Hibernate Validator 9.1
#50332 - Add a CLI command to decrypt secrets
#50723 - OIDC token propagation - allow users to select REST Client methods for which token should be propagated
#50806 - Support method-level @OidcClientFilter bindings
#50952 - Use @QuarkusIntegrationTest tests as a test run for AOT file generation

As usual, this release also includes many bug fixes and improvements.

Update

To update to Quarkus 3.30, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.30.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.30 migration guide.

変更点

RESTクライアント

@JsonView support has been added to the REST Client. You can now use this annotation on your REST Client interfaces to control the serialization and deserialization of JSON data based on different views.

This feature used to be only supported on the server side.

Hibernate Validator

Hibernate Validator has been updated to version 9.1, which comes with some significant performance improvements.

コマンドラインインタフェース

A new config decrypt command has been added to the Quarkus CLI to decrypt secrets that were encrypted using the quarkus config encrypt command.

OIDC

OIDC token propagation has been enhanced to allow users to select specific REST Client methods for which the token should be propagated.

Additionally, method-level @OidcClientFilter bindings are now supported, allowing for more granular control over OIDC client behavior.

AOT cache

@QuarkusIntegrationTest tests are now used as a test run for AOT file generation.

完全な変更履歴

You can get the full changelog of 3.30.0.CR1, 3.30.0, and 3.30.1 on GitHub.

コントリビューター

The Quarkus community is growing and has now 1136 contributors. Many many thanks to each and everyone of them.

In particular for the 3.30 release, thanks to Ales Justin, Alexey Loubyansky, Andreas Repp, Andy Damevin, Antonio Musarra, Aurea Munoz, azerr, Bruno Baptista, Christian Pieczewski, Clement Escoffier, David M. Lloyd, Eric Deandrea, eschcam, Foivos Zakkak, Fouad Almalki, Galder Zamarreño, George Gastaldi, Georgios Andrianakis, Greg Stewart, Guillaume Smet, Holly Cummins, Jakub Pietrzak, James Netherton, Jan Martiska, jcarranzan, jcjveraa, Johannes Schleger, Jonas Rutishauser, Juan Antonio Breña Moral, Julien Ponge, Junior DUSSOUILLEZ, Karm Michal Babacek, Kevin Ferrare, Ladislav Thon, Loïc Hermann, Luca Molteni, Lucas Reeh, Maciej Swiderski, Manuel Müller, Marco Belladelli, mariofusco, marko-bekhta, Martin Kouba, Matej Novotny, Matej Vašek, Matheus Cruz, Melloware, Michael Edgar, Michal Vavřík, Nicolo Pietro Belcastro, Ozan Gunalp, Peter Palaga, Phillip Krüger, Pierre Beitz, Robert Stupp, Roberto Cortez, Rolfe Dlugy-Hegwer, Rostislav Svoboda, Sanne Grinovero, Sergey Beryozkin, staillebois, Stéphane Épardaud, Teymur Babayev, Thomas Segismont, Tomas Hofman, Willem Jan Glerum, xstefank, and Yoann Rodière.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.29.4 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Thu, 20 Nov 2025 00:00:00 +0000

Today, we released Quarkus 3.29.4, a new maintenance release for our 3.29 stream.

Update

To update to Quarkus 3.29, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.29.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.29 migration guide.

完全な変更履歴

You can get the full changelog of 3.29.4 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.27.1 released - LTS maintenance release

Jan Martiška (https://twitter.com/janmartiska) — Wed, 19 Nov 2025 00:00:00 +0000

Today, we released Quarkus 3.27.1, our first maintenance release for the 3.27 LTS stream.

This release contains bugfixes, documentation updates and fixes a CVE in the Microsoft SQL JDBC driver: CVE-2025-59250

It should be a safe upgrade for anyone already using 3.27.

Update

To update to Quarkus 3.27, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update --stream=3.27

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.27.

完全な変更履歴

You can get the full changelog of 3.27.1 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.20.4 released - LTS maintenance release

Jan Martiška (https://twitter.com/janmartiska) — Wed, 19 Nov 2025 00:00:00 +0000

Today, we released Quarkus 3.20.4, our next maintenance release for the 3.20 LTS stream.

This release contains bugfixes, documentation updates and fixes the following CVE:

CVE-2025-59250

It should be a safe upgrade for anyone already using 3.20.

Update

To update to Quarkus 3.20, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update --stream=3.20

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.20.

完全な変更履歴

You can get the full changelog of 3.20.4 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus 3.29.3 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Fri, 14 Nov 2025 00:00:00 +0000

Today, we released Quarkus 3.29.3, a new maintenance release for our 3.29 stream.

Among other issues, this release fixes a compatibility issue of Testcontainers with recent Docker versions.

Update

To update to Quarkus 3.29, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.29.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.29 migration guide.

完全な変更履歴

You can get the full changelog of 3.29.3 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

Quarkus Micrometer using Prometheus client v1

Bruno Baptista — Fri, 14 Nov 2025 00:00:00 +0000

Quarkus Micrometer using Prometheus client v1

Micrometer adopted Prometheus Client v1.x starting with version 1.13. However, Quarkus still uses Prometheus Client v0.x by default through the quarkus-micrometer-registry-prometheus extension which has been using the legacy io.prometheus:simpleclient. This is now considered deprecated and will not be part of the future Quarkus 4.x version (still no timeline).

In parallel, we have introduced a new extension in Quarkiverse: quarkus-micrometer-registry-prometheus-v1, which integrates the new v1.x client.

<dependency>
    <groupId>io.quarkiverse.micrometer.registry</groupId>
    <artifactId>quarkus-micrometer-registry-prometheus-v1</artifactId>
</dependency>

Since the new client introduces breaking changes, we’ve prepared a migration plan designed to reduce the impact on existing users.

Some of the changes affect the names of some metrics. This requires queries and dashboards to be updated in order to continue working. Users should evaluate the impacts for their projects before moving to the new quarkus-micrometer-registry-prometheus-v1 extension.

The old and the new extension should not be used at the same time as the both require the /q/metrics endpoint.

Migrating to the new extension

Users can keep current extension as is until Quarkus 4.0 allowing them to migrate at a time of their choice.
We are introducing the new extension quarkus-micrometer-registry-prometheus-v1 and users can start migrating their projects to it right now.
For Quarkus 4.0 we will introduce the following changes:
- The deprecated quarkus-micrometer-registry-prometheus extension will be moved from Quarkus core repo to Quarkiverse, allowing an additional migration period.
- The new quarkus-micrometer-registry-prometheus-v1 extension will be moved from Quarkiverse to Quarkus core repo, making it the default registry.

Breaking changes

As mentioned above, the new extension comes with a set of breaking changes.

Prometheus client v1

The quarkus-micrometer-registry-prometheus-v1 extension will be using the Prometheus Client v1.x and includes breaking changes expressed in detail on the Micrometer 1.13 Migration Guide, featuring package, API and semantic convention changes.

These are the main points to consider when migrating to the new Quarkus extension:

Counters now use Longs instead of Doubles.
- Before: "registry=\"prometheus\",status=\"200\",uri=\"/example/prime/{number}\"} 2.0
- Now: "registry=\"prometheus\",status=\"200\",uri=\"/example/prime/{number}\"} 2
io.micrometer.prometheusmetrics.PrometheusMeterRegistry must be used instead of the old io.micrometer.prometheus.PrometheusMeterRegistry.
io.prometheus.metrics.tracer.common.SpanContext must be used instead of the old io.prometheus.client.exemplars.ExemplarSampler
The new Prometheus client uses some reserved words that must not be used to name metrics, therefore some metrics were renamed. Some examples of reserved words and renamed metrics:
- info. Before: jvm_info_total. Now: jvm_total
- duration. Before: http_server_requests_duration_seconds. Now: http_server_requests_seconds
Some metrics would display Tags ending in a comma (,). This tailing comma has now been removed. Example: hibernate_flushes_total{entityManagerFactory=\"<default>\",env=\"test\",env2=\"test\",registry=\"prometheus\",} 1.0
It is no longer possible to create a metric generating Service Level Objectives and Percentiles at the same time.

Change when registering metrics:

Metrics must be registered always with the same tags. Micrometer will now send a warning if we register the same metric more than once with different Tag names.

Implementation changes

Quarkus automatic instrumentation will generate metrics reflecting these changes. If your application defines custom metrics, be sure to update their creation, associated tests, and any dashboard queries to align with the guidelines above.

About metrics in Quarkus

The Micrometer extension is the recommended approach to generate metrics in Quarkus and this a rare occasions were breaking changes are being introduced.

Micrometer has become the default metrics framework in Quarkus due to its stability, maturity, and widespread adoption on the Java ecosystem — not OpenTelemetry Metrics.

Micrometer integration in Quarkus is provided through the core quarkus-micrometer` extension. Specific registry extensions depend on this core extension and implement their own registries to export telemetry data. The Prometheus registry (quarkus-micrometer-registry-prometheus) is the default and most commonly used, and it is the focus of this announcement.

However, there are alternative ways to export metrics using Micrometer:

Through the Quarkiverse Micrometer registries
Via OpenTelemetry, using a bridge provided by the Micrometer and OpenTelemetry extension. This setup allows Micrometer metrics to be sent as OpenTelemetry metrics, offering a unified output via the OpenTelemetry OTLP protocol.

For more details on Observability in Quarkus please visit this guide.

まとめ

While the existing Prometheus registry remains available for the Quarkus 3.x lifecycle, it is now deprecated, and users are encouraged to begin migrating to the new extension because the old client extension will be removed on Quarkus 4.0 (no timeline at this moment).

This change introduces a number of breaking updates aligned with Micrometer 1.13 and Prometheus Client v1.x, affecting metric types, naming conventions, and APIs.

To support users, a migration plan has been outlined to provide flexibility and minimize disruption.

The prometheus client is not the only option to send out telemetry, there are alternative options such as the Quarkiverse registries or our OpenTelemetry bridge.

Quarkus Newsletter #62 - November

James Cobb (https://twitter.com/insectengine) — Thu, 13 Nov 2025 00:00:00 +0000

Discover what most Java developers miss—AI assistants, dynamic Qute templates, auto-refreshing tokens, and reactive magic in "You’re Only Using Half of Quarkus: 10 Hidden Features That Change Everything" by Markus Eisele. Farah Juma’s blog post "How to Secure Your A2A Server Agent with Keycloak OAuth2" shows how to secure an A2A server agent using OAuth2 bearer tokens via Keycloak and shows how to enable an A2A client to automatically obtain and pass the required token in each request. "Hexagonal Architecture in Java: Structuring Your APIs for Maintainability" by lostyzen is a complete guide to hexagonal architecture in Java with Quarkus: structure, concrete examples, testing, and best practices for maintainable and scalable APIs. Read about Quarkus’s continued focus on native for swift start-up time and low memory footprint in Severin Gehwolf' article, "Continued Focus on Native". If you want to test the business logic of your components in isolation, with different configurations and inputs, then QuarkusComponentTest is a good choice. It’s fast, integrated with continuous testing, and extensible. Learn more about by reading Martin Kouba’s article "Quarkus - a component testing update". Explore Qute’s dynamic include feature in Quarkus 3.26 and learn how to build modular, data-driven dashboards for modern enterprise apps. Learn more in "Dynamic UI Composition with Quarkus Qute: The Future of Java Frontends" by Markus Eisele.

You will also see the latest Quarkus Insights episodes, top tweets/discussions and upcoming Quarkus attended events.

Check out Newsletter #62: November!

ニュースレターを受信してみませんか？ページ上のフォームを使ってニュースレターに登録してください。

Agentic AI Patterns: one size does not fit all

Mario Fusco (https://twitter.com/mariofusco) — Wed, 12 Nov 2025 00:00:00 +0000

At the beginning of 2025, we began experimenting with agentic AI using Quarkus and its LangChain4j extension. These efforts led to the publication of a three-part blog post series on the topic: the first introduced agentic AI and workflow patterns, the second explored purely AI-orchestrated agentic patterns, and the third examined the differences between these two approaches through a practical example, highlighting their respective pros and cons.

Only a few months have passed since those articles were published, yet the AI ecosystem and the possibilities it unlocks have evolved at an incredible pace. Keeping up with the constant stream of novelties and changes has become increasingly challenging. In fact, the initial experiments from that series now seem to belong to a different era, even though they laid the essential groundwork for exploring the agentic AI landscape.

These experiments and explorations led to the implementation of a new agentic module in LangChain4j, designed to provide a comprehensive toolkit for building agentic AI systems. The module also includes a set of predefined agentic patterns that serve as building blocks for coordinating agents in different ways. However, as we continued experimenting and, more importantly, discussing our findings with the LangChain4j community, it became clear that believing this set of patterns could fully cover all possible use cases was somewhat naive. In reality, the landscape is far more complex and nuanced.

Agentic AI at Devoxx Belgium 2025

Agentic AI was, by far, one of the most discussed topics at Devoxx Belgium 2025, and we had the opportunity to present the agentic AI patterns implemented in LangChain4j. In fact, we delivered both a talk showcasing practical examples of how these patterns work and how to use them, and a session that delved deeper into the journey behind implementing the agentic framework, including the key decisions we made and the mistakes we learned from along the way.

As always at Devoxx, what mattered even more than attending the countless talks on agentic AI was the opportunity to meet so many people working in this field, exchanging ideas, sharing experiences, and discussing challenges and solutions.

We learned a great deal from these interactions and returned home with one clear realization: we will never find a definitive pattern for agent orchestration. Not only is this beyond our specific area of expertise, but more importantly, such a universal pattern simply doesn’t exist. The variety and complexity of tasks that an agentic system may need to handle mean that no single approach can work in every situation: there is no one-size-fits-all solution for agentic AI orchestration.

In reality, there is a broad spectrum of agentic patterns, ranging from reliable and deterministic yet rigid workflows, where agents follow predefined code and flow paths, to flexible yet unpredictable pure agentic orchestrations, where LLMs autonomously determine the sequence of actions and maintain control over task execution. Between these two extremes lies what might be the most interesting space: one that balances reliability and flexibility. And since precisely defining that middle ground is challenging, why not give users the ability to shape it according to their specific needs?

A generic architecture for agentic AI patterns

The natural outcome of these reflections was the decision to design a generic architecture for agentic AI patterns: one flexible enough to support a wide variety of use cases, while still allowing these patterns to function as modular building blocks that can be seamlessly combined and complement one another.

To ensure maximum flexibility, we needed to identify the simplest and most minimal abstraction capable of doing the job. This led us to realize that an agentic pattern, at its core, is the specification of an execution plan for the subagents it coordinates. Such a plan can be defined by implementing the following Planner interface:

public interface Planner {

    default void init(InitPlanningContext initPlanningContext) { }

    default Action firstAction(PlanningContext planningContext) {
        return nextAction(planningContext);
    }

    Action nextAction(PlanningContext planningContext);
}

This interface, that still has to be considered experimental and could be enriched or modified in other ways with subsequent revisions, defines a method for initializing the planner, along with two methods responsible for determining the first action to execute and all subsequent ones. The method that returns the first action is optional; by default, it simply delegates to the method that returns the next action, which is the only one that must be implemented. The Action class returned by these methods represents the next step to be taken by the agentic pattern. It can either specify one or more subagents to be invoked next or signal that the execution has completed.

In essence, the architecture of the LangChain4j agentic framework can be seen as a two-layered system, where the planner layer is responsible for determining the sequence of agent invocations, while the execution layer handles the actual execution of these agents based on the planner’s directives. Both layers are designed to be easily extensible, allowing users to implement custom planners and execution frameworks like Quarkus to adapt some runtime aspects, like the thread pool used to run the different agents, to its needs. The AgenticScope acts as the shared context between these two layers, maintaining the state of the entire agentic system throughout its execution.

Figure 1. The planner and execution layers of the LangChain4j agentic architecture

All the built-in agentic patterns provided out of the box by the langchain4j-agentic module have been rewritten using this new Planner abstraction. The pull requests implementing this architecture have already been merged, and this article won’t go into much detail about their internals here, as you can find a full explanation in its description.

Another important aspect to consider is that this new architecture not only allows users to implement their own agentic patterns but also makes it easy to combine them with any other pattern, whether provided by LangChain4j or created by users themselves. Since all patterns are now defined in terms of a Planner, any pattern can serve as a subagent within another, opening the door to an almost infinite variety of combinations. The following example illustrates this concept in practice.

Mixing multiple agentic patterns

One of the examples included in the pull request mentioned earlier illustrates this new architecture by showing how to create a custom agentic pattern based on a goal-oriented strategy. This approach determines the sequence of agents to be invoked to accomplish a specific complex task.

To put this approach into practice, the entire agentic system must define a final goal, and each subagent must declare its own preconditions, the requirements needed to perform its task, and postconditions, which describe the outcomes guaranteed once execution is complete. However, in agentic LangChain4j, all this information is already implicitly available: the preconditions and postconditions correspond to each agent’s required inputs and produced outputs, while the final goal represents the desired outputs of the entire agentic system.

Following this idea, we can calculate a dependency graph of all the subagents participating in the agentic system. Based on that graph, it’s then possible to implement a Planner capable of analyzing the initial state of the AgenticScope, comparing it with the desired goal, and determining the sequence of agent invocations that can lead to achieving that goal.

public class GoalOrientedPlanner implements Planner {

    private String goal;

    private GoalOrientedSearchGraph graph;
    private List<AgentInstance> path;

    private int agentCursor = 0;

    @Override
    public void init(InitPlanningContext initPlanningContext) {
        this.goal = initPlanningContext.plannerAgent().outputKey();
        this.graph = new GoalOrientedSearchGraph(initPlanningContext.subagents());
    }

    @Override
    public Action firstAction(PlanningContext planningContext) {
        path = graph.search(planningContext.agenticScope().state().keySet(), goal);
        if (path.isEmpty()) {
            throw new IllegalStateException("No path found for goal: " + goal);
        }
        return call(path.get(agentCursor++));
    }

    @Override
    public Action nextAction(PlanningContext planningContext) {
        return agentCursor >= path.size() ? done() : call(path.get(agentCursor++));
    }
}

As mentioned earlier, in this example, the goal corresponds to the final output of the planner-based agentic pattern itself. The path from the initial state to that goal is computed using a graph built by analyzing the input and output keys of all subagents. The sequence of agents to invoke is then determined as the shortest path on that graph, connecting the current state to the desired goal.

The example discussed in the pull request to demonstrate this pattern in action is an agentic system that generates horoscope-based write-ups. The complete source code is available here. This system is composed of several subagents, each responsible for a specific task, such as extracting user data from the prompt, fetching horoscope information from an external source, generating content based on that data, and formatting the final write-up. In this setup, the graph of agent dependencies, which also determines the sequence of their activations, is as follows:

Figure 2. The GOAP-determined sequence of agents invocation to generate an horoscope-based writeup

The primary advantage of this goal-oriented strategy is that it deterministically identifies the shortest sequence of steps necessary to transition from the initial state to the final goal. However, in some cases, a sequence of agent invocations calculated purely along the optimal path in the dependency graph can become a limitation. For instance, by definition, a shortest path contains no loops, yet in practice, a loop may be necessary to allow an agent to reflect on its own work and iteratively refine its output.

As mentioned earlier, the LangChain4j agentic framework overcomes this limitation by allowing seamless integration of the goal-oriented system with any other agentic pattern, whether provided by the framework or custom-built. For example, the final agent responsible for generating the write-up could be complemented by a reflection loop, using another agent that evaluates and scores the generated content.

public interface Writer {
    @UserMessage("""
            Create an amusing writeup for {{person}} based on the following:
            - their horoscope: {{horoscope}}
            - a current news story: {{story}}
            """)
    @Agent("""
           Create an amusing writeup for the target person based
           on their horoscope and current news stories
           """)
    String write(@V("person") Person person,
                 @V("horoscope") String horoscope,
                 @V("story") String story);
}

public interface WriteupScorer {

    @UserMessage("""
            You are a critical reviewer. Give a review score between 0.0 and 1.0
            for the following writeup
            based on how well it aligns with the spirit of the given zodiac sign.
            Return only the score and nothing else.

            The writeup is: "{{writeup}}"
            The sign is: "{{sign}}"
            """)
    @Agent("Scores a story based on how well it aligns with a given style")
    double scoreWriteup(@V("writeup") String writeup, @V("sign") Sign sign);
}

public interface WriteupAndReviewLoop {
    @Agent
    String write(@V("person") Person person,
                 @V("horoscope") String horoscope,
                 @V("story") String story);
}

In this setup, the single Writer agent can be replaced by a reflection loop, allowing the final agentic system to overcome one of the typical limitations of the goal-oriented strategy. The resulting system can then be defined as follows:

Writer writer = AgenticServices.agentBuilder(Writer.class)
        .chatModel(baseModel())
        .outputKey("writeup")
        .build();

WriteupScorer scorer = AgenticServices.agentBuilder(WriteupScorer.class)
        .chatModel(baseModel())
        .outputKey("score")
        .build();

WriteupAndReviewLoop writeAndReviewLoop = AgenticServices
        .loopBuilder(WriteupAndReviewLoop.class)
        .subAgents(writer, scorer)
        .outputKey("writeup")
        .exitCondition( agenticScope -> agenticScope.readState("score", 0.0) >= 0.8)
        .maxIterations(5)
        .build();

UntypedAgent horoscopeAgent = AgenticServices.plannerBuilder()
        .subAgents(horoscopeGenerator, personExtractor,
                   signExtractor, writeAndReviewLoop, storyFinder)
        .outputKey("writeup")
        .planner(GoalOrientedPlanner::new)
        .build();

まとめ

An agentic system composed of multiple small, specialized agents can often outperform a single large language model–based AI service, and do so at a fraction of the cost. However, using many interoperating agents introduces the challenge of coordinating them effectively to accomplish complex tasks. Different agentic patterns present distinct trade-offs between reliability and flexibility, and no single approach is suitable for all scenarios. This is why a customizable architecture that enables users to define and combine diverse agentic patterns is essential for building truly adaptable AI systems.

By introducing a generic Planner interface, LangChain4j empowers users to design their own agentic patterns and seamlessly integrate them with existing ones. This flexibility enables the creation of sophisticated, purpose-driven agentic systems that balance the strengths of different orchestration strategies to meet specific needs.

This also opens the door for users to contribute to the LangChain4j agentic ecosystem by sharing their own Planner implementations. To support this, a new dedicated module, named langchain4j-agentic-patterns, has been added to the LangChain4j project. Its goal is to collect and maintain a growing set of reusable agentic patterns that can serve as building blocks for creating complex, robust agentic systems.

Quarkus 3.29.2 - Maintenance release

Guillaume Smet (https://twitter.com/gsmet_) — Sat, 08 Nov 2025 00:00:00 +0000

Today, we released Quarkus 3.29.2, a new maintenance release for our 3.29 stream.

We skipped the 3.29.1 announcement as we detected a regression shortly after the release and decided to release 3.29.2 right away. The regression was caused by a problem in how binaries were detected in the $PATH specfically on Windows.

Update

To update to Quarkus 3.29, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Note that quarkus update can update your applications from any version of Quarkus (including 2.x) to Quarkus 3.29.

For more information about the adjustments you need to make to your applications, please refer to the Quarkus 3.29 migration guide.

完全な変更履歴

You can get the full changelog of 3.29.1 and 3.29.2 on GitHub.

参加のお誘い

Quarkusユーザーの場合でも、単に興味を持っているだけの場合でも、恥ずかしがらずにコミュニティに参加して下さい!:

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
Stack Overflow で質問

ArC migrates to Gizmo 2

Ladislav Thon (https://twitter.com/_Ladicek) — Mon, 03 Nov 2025 00:00:00 +0000

ArC is Quarkus’s implementation of CDI Lite. Gizmo is a simplified bytecode generation library. What do they have in common?

ArC has been using Gizmo 1 since approximately forever, but now that Gizmo 2 is shaping up, some Quarkus components have started migrating to it. I have started rewriting ArC to Gizmo 2 a few months ago, when we felt like Gizmo 2 starts looking reasonable and some real-world experience was needed.

This rewrite took several months, mostly because Gizmo 2 is a complete rewrite and rearchitecture of Gizmo 1 and ArC is a heavy user, but also because during the ArC rewrite, I found some Gizmo 2 issues and there were several back and forths.

To illustrate, I’ll first go over the differences in Gizmo 1 and 2, and then detail how that affects ArC users. Spoiler alert: there’s no change that would affect Quarkus applications. All changes are in the APIs that are only exposed to extensions (at build time).

Gizmo 1 vs Gizmo 2

First off, Gizmo 1 is based on ASM and Gizmo 2 is based on the ClassFile API (not the one present in the JDK since version 24, but the fork maintained by David Lloyd, which supports Java 17). The ClassFile API itself is very different to ASM, and since the ClassFile API structure guided the Gizmo 2 API structure, that is also very different.

To quickly compare, this is how you generate a "Hello, World!" program with Gizmo 1:

ClassOutput output = ...;
try (ClassCreator creator = ClassCreator.builder()
        .classOutput(output)
        .className("com.example.Hello")
        .build()) {
    MethodCreator method = creator.getMethodCreator("main", void.class, String[].class)
            .setModifiers(Modifier.PUBLIC | Modifier.STATIC);
    Gizmo.systemOutPrintln(method, method.load("Hello, World!"));
    method.returnVoid();
}

And this is how you generate the same program with Gizmo 2:

Gizmo gizmo = Gizmo.create(ClassOutput.fileWriter(Path.of("target")));
gizmo.class_("com.example.Hello", cc -> {
    cc.defaultConstructor();

    cc.staticMethod("main", mc -> {
        ParamVar args = mc.parameter("args", String[].class);
        mc.body(bc -> {
            bc.printf("Hello, World!%n");
            bc.return_();
        });
    });
});

There are obvious surface-level differences in the API structure, but there are also deeper differences. I’ll mention one here just as an example: the way Gizmo represents and maintains values has changed significantly.

Gizmo 1 has the venerable ResultHandle class, which is almost always a local variable (even though the API doesn’t let you assign to it; you have to use AssignableResultHandle for that). This means you don’t really have to care about order in which you produce values or about using them multiple times — everything just works. There’s obvious overhead though: for each use of the value, it needs to be loaded from the variable to the stack.

On the other hand, Gizmo 2 represents values as Exprs, which are not local variables:

Expr hello = bc.invokeVirtual(
        MethodDesc.of(String.class, "concat", String.class, String.class),
        Const.of("Hello"), Const.of(" World"));

An Expr is a value that is, at the time of its creation, on top of the stack, nothing more. This means the order of producing values suddenly matters and they may not be reused! To create a local variable (LocalVar) out of an expression, you have to explicitly call a method:

LocalVar hello = bc.localVar("hello", bc.invokeVirtual(
        MethodDesc.of(String.class, "concat", String.class, String.class),
        Const.of("Hello"), Const.of(" World")));

There are a lot more concepts not shown in these examples, which you can read about in the documentation. The Gizmo 1 documentation is available at https://github.com/quarkusio/gizmo/blob/1.x/USAGE.adoc, while the Gizmo 2 documentation (not yet complete) is available at https://github.com/quarkusio/gizmo/blob/main/MANUAL.adoc.

ArC

Back to ArC. Today, all bytecode generation in ArC is based on Gizmo 2 (if you want the gory details, look at this pull request), and it’s going to be released in Quarkus 3.30.

ArC has several public APIs that expose Gizmo types. This means that the rewrite to Gizmo 2 includes breaking changes. These are unlikely to impact users — in fact, the number of affected places in the Quarkus core repository is surprisingly small. However, in the interest of transparency, here’s a full list of API breakages:

BeanConfiguratorBase: methods

THIS creator(Consumer<MethodCreator> methodCreatorConsumer)
THIS destroyer(Consumer<MethodCreator> methodCreatorConsumer)
THIS checkActive(Consumer<MethodCreator> methodCreatorConsumer)

were changed to

THIS creator(Consumer<CreateGeneration> creatorConsumer)
THIS destroyer(Consumer<DestroyGeneration> destroyerConsumer)
THIS checkActive(Consumer<CheckActiveGeneration> checkActiveConsumer)

ObserverConfigurator: method

ObserverConfigurator notify(Consumer<MethodCreator> notifyConsumer)

was changed to

ObserverConfigurator notify(Consumer<NotifyGeneration> notifyConsumer)

ContextConfigurator: method

ContextConfigurator creator(Function<MethodCreator, ResultHandle> creator)

was changed to

ContextConfigurator creator(Function<CreateGeneration, Expr> creator)

BeanProcessor.Builder: method

Builder addSuppressConditionGenerator(Function<BeanInfo, Consumer<BytecodeCreator>> generator)

was changed to

Builder addSuppressConditionGenerator(Function<BeanInfo, Consumer<BlockCreator>> generator)

Noone is expected to be affected by the last change, because that is in the ArC integration API, which should only be used by the Quarkus ArC extension. The other changes are in APIs that could legitimately be used:

synthetic beans
synthetic observers
custom contexts

As you see, all these changes are similar. The Gizmo 1 variant takes a Consumer<MethodCreator> (or, in one case, a Function<MethodCreator, ResultHandle>). The MethodCreator must be used to create the bytecode of the corresponding method:

BeanConfiguratorBase.creator(): create an instance of the synthetic bean
BeanConfiguratorBase.destroyer(): destroy an instance of the synthetic bean
BeanConfiguratorBase.checkActive(): check if the synthetic bean is currently active (niche use case, most likely unused outside of the core Quarkus repository)
ObserverConfigurator.notify(): notify the synthetic observer
ContextConfigurator.creator(): create a context object of the custom context

The Gizmo 2 variants no longer take a Gizmo object. Instead, they take an ArC interface that provides access to all the necessary Gizmo objects — because more than 1 is necessary.

As mentioned above, most extensions should not be affected. This is because higher-level APIs exist that do not expose bytecode generation; either they use classes that implement interfaces, or they accept results of recorder methods. These higher-level APIs didn’t change at all. However, using the lower-level APIs is still permitted, so let’s take a look at how we’d migrate a simple synthetic bean creation function from Gizmo 1 to Gizmo 2.

Here’s a simple synthetic bean registered using SyntheticBeanBuildItem:

SyntheticBeanBuildItem.configure(String.class)
        .scope(Singleton.class)
        .param("message", "Hello, World!")
        .creator(mc -> {
            ResultHandle params = mc.readInstanceField(
                    FieldDescriptor.of(mc.getMethodDescriptor().getDeclaringClass(),
                            "params", Map.class),
                    mc.getThis());
            ResultHandle message = Gizmo.mapOperations(mc).on(params).get(mc.load("message"));
            ResultHandle instance = mc.invokeVirtualMethod(
                    MethodDescriptor.ofMethod(String.class,
                            "concat", String.class, String.class),
                    mc.load("Message: "), message);
            mc.returnValue(instance);
        })
        .done();

The Consumer here accepts a MethodCreator that provides direct access to its parameters as well as to the class, from which one can read the fields.

After the rewrite to Gizmo 2, the code looks like:

SyntheticBeanBuildItem.configure(String.class)
        .scope(Singleton.class)
        .param("message", "Hello, World!")
        .creator(cg -> {
            BlockCreator bc = cg.createMethod();

            Var params = cg.paramsMap();
            Expr message = bc.withMap(params).get(Const.of("message"));
            Expr instance = bc.invokeVirtual(
                    MethodDesc.of(String.class,
                            "concat", String.class, String.class),
                    Const.of("Message: "), message);
            bc.return_(instance);
        })
        .done();

The Consumer accepts CreateGeneration that provides access to the BlockCreator to generate bytecode (createMethod()) and a number of necessary variables. In this example, we use the paramsMap() method to acccess the parameter map.

The other APIs have changed in the same manner: instead of MethodCreator, the Consumer accepts *Generation which provides access to the BlockCreator and the necessary variables.

One might ask: why does the new API provide access to a BlockCreator and not to a MethodCreator, which clearly still exists in Gizmo 2? And it would be a good question. The answer, as it turns out, is efficiency. The previous API that did provide access to a MethodCreator required generating a whole new method that would only host the user-generated code. The new API that doesn’t provide access to a MethodCreator allows embedding the user-generated code into a method that contains other, ArC-generated code. Thus, the number of methods in the generated classes is smaller and the generated code is more compact.

まとめ

Gizmo 2 is an evolution (some might say revolution) of Gizmo 1, the simplified bytecode generation library used by all of Quarkus. ArC is a heavy user of Gizmo and it just recently migrated to Gizmo 2. There are some breaking changes that might affect Quarkus extensions (not applications).

In this post, we reviewed the API breakages and showed a simple migration scenario. Hopefully, your extensions are not affected, because they use the higher-level APIs, but if they are, you’ll need to migrate as well. Then, your extension will only be compatible with Quarkus 3.30 and above; it will stop working with previous versions. Plan accordingly.

Continued Focus on Native

Severin Gehwolf — Mon, 03 Nov 2025 00:00:00 +0000

From its inception, Quarkus has offered the ability to compile Java applications into native binaries. This feature is crucial for achieving rapid startup times and reduced memory consumption, two properties that remain paramount to Quarkus' mission and that Quarkus remains committed to.

We have already started preparing for the adoption of GraalVM 25 (via our Mandrel distribution), and expect to switch to it as the primary native builder in the near future.

Quarkus uses the Mandrel GraalVM distribution to ensure continuity of updates on native-image capabilities. Mandrel 25 empowers Quarkus users to leverage the latest JDK innovations (JDK 25) and target cloud-native deployments through its native compilation capabilities. Our collaboration with the upstream GraalVM community during GraalVM 25’s development has strengthened our involvement, bringing these shared innovations directly to Quarkus users with the incorporation of the Mandrel 25 release.

Key improvements that Mandrel 25 and Quarkus are expected to bring:

Readiness for JDK 25 - Enhanced Compatibility and Stability: Mandrel 25, based on OpenJDK 25, offers improved compatibility with the latest OpenJDK features and libraries, ensuring that Quarkus applications can leverage the full spectrum of the Java ecosystem while maintaining the stability and reliability expected of production-ready enterprise systems.
Continued Focus on Key Metrics: Mandrel 25 will be the technology of choice in order to deliver on the cloud-native performance goals of fast startup and low memory footprint of Quarkus releases for the next years to come. Quarkus continues to enable aggressive initialization at build time to achieve this.
Enhanced Static Analysis Accuracy: GraalVM 25 enables Whole-Program Sparse Conditional Constant Propagation (WP-SCCP) by default, improving the precision of points-to analysis in native image. This optimization enhances static analysis accuracy and scalability, potentially reducing the size of the final native binary. More information on the GraalVM blog.
Improved Error Reporting and Diagnostics: When resources or certain reflective accesses aren’t properly registered at image build time, it is now being appropriately flagged by raising a specific exception when building with Mandrel 25. Flags, -XX:MissingRegistrationReportingMode=Warn and -XX:MissingRegistrationWarnContextLines=<#lines> can be used to diagnose. The ability to handle OutOfMemoryError was added.
Enhanced Monitoring Possibilities: By leveraging Mandrel 25 more monitoring options of the deployed native Quarkus application binary become possible closing the gap between JVM mode and native mode. New JFR events, such as Socket IO and native memory tracking events as well as JFR allocation profiling become possible (via the jdk.ObjectAllocationSample event). The addition of Java Diagnostic Command (JCMD) allows for triggering of certain actions on the running native image. The JFR monitoring feature of native image has been enhanced to be more configurable (via -XX:FlightRecorderOptions), previously only available in JVM mode. Native memory tracking can be optionally enabled in order to diagnose memory leaks (using -Dquarkus.native.monitoring=nmt at build time and -XX:+PrintNMTStatistics at runtime)
Full Support for the Foreign Function & Memory (FFM) API: Quarkus applications can now make use of full support of the FFM API (included in JVM mode since JDK 22) when compiling to native using Mandrel 25. Upcall and downcall support has been added for all supported Quarkus operating systems and architectures.

By seamlessly integrating Mandrel 25, and Quarkus’ continued focus on developer joy and productivity, together with new and emerging AI capabilities further solidifies Quarkus’s position as the premier framework for building high-performance, cloud-native Java applications. Developers can confidently leverage these advancements to deploy applications that are not only efficient but also deliver exceptional user experiences. Quarkus and Mandrel 25 combine to create a powerful synergy that pushes the boundaries of Java in today’s modern computing landscape. This combination delivers on Quarkus’s Cloud Native Mission, offering swift start-up times and a low memory footprint.

Looking Ahead

Beyond GraalVM 25, we are tracking the evolution of GraalVM closely as we have done in the past and will continue to work with the GraalVM team to evolve accordingly and ensure that Quarkus integrates well with it. We expect to see some promising and useful new features in coming releases, not the least:

Shenandoah GC integration
Project Crema and dynamic Java on top of native-image. This will unlock Java use cases that today cannot run as native-image
Native Image Layers to make it possible to tune performance vs. usability
Polyglot - First-class JavaScript, Python and Wasm integrations

GraalVM Community Collaboration and GraalVM Summit

The collaboration between Quarkus, Mandrel and GraalVM developers continues to be strong. What’s more, Mandrel is being developed as part of the GraalVM Github organization and the GraalVM for JDK 21 community effort was established as part of those community gatherings. Mandrel developers assumed maintainer roles for the GraalVM for JDK 21 maintenance repository. We hope to establish a similar model for GraalVM 25 and its downstream, Mandrel 25. The Mandrel team is certainly interested in stepping up for community maintenance of GraalVM 25 when the time comes.

For the past few years Quarkus and Mandrel developers have been attending the GraalVM Community summit. A powerful platform to exchange ideas and experience with the GraalVM technology. In 2025, five Quarkus/Mandrel developers attended the GraalVM Community Summit. We believe the event was a great success. These gatherings are paramount to the Quarkus and GraalVM collaboration. We were glad to see that there is shared interest in making the public GraalVM github repository a true upstream with an open governance model. This would further strengthen the GraalVM community and would help self-sustain certain areas. Some of this has been already tested with the GraalVM for JDK 21 upstream community repository.

Commitment to delivering "Supersonic Subatomic Java"

The Quarkus project will continue to evaluate and incorporate the best available technologies to ensure its users benefit from optimal reliability, performance, and efficiency. This includes exploring advancements in all technologies and runtime environments as they evolve, such as project Leyden. Our goal remains to ensure that Quarkus remains at the forefront of cloud-native Java development. Our commitment is to provide developers with the flexibility to choose the tools that best fit their project’s needs, while always delivering on our promise of "Supersonic Subatomic Java", and provide optimal, highly efficient deployment formats for a broad range of environments.

Onward with Quarkus Native!

You can share your feedback with us in Quarkus' Zulip chat workspace or on GitHub.