Quarkus

Introducing Quarkus Agent MCP: teaching AI agents to speak Quarkus

Phillip Kruger (https://twitter.com/phillipkruger) — Thu, 07 May 2026 00:00:00 +0000

AI coding agents like Claude Code, GitHub Copilot, Cursor, Windsurf, and JetBrains AI are already capable of generating code, fixing bugs, and refactoring entire modules. But they become much more effective when they have context about the framework you are using: that Quarkus dev mode hot-reloads on the next request rather than on file save, that Panache entities need @Transactional for writes, that REST clients should be injected via CDI rather than instantiated manually.

Quarkus Agent MCP gives agents exactly that context. It is a standalone MCP (Model Context Protocol) server that lets any compatible AI agent create, manage, and work effectively with Quarkus applications by providing Quarkus-specific tools, documentation, and extension-level coding patterns.

What is MCP?

The Model Context Protocol is an open standard that lets AI agents discover and use tools exposed by external servers. Instead of hard-coding integrations for every framework, an agent connects to MCP servers that provide domain-specific capabilities. The agent discovers available tools at runtime and calls them as needed.

It’s a plugin system for AI agents: connect to a server and the agent gains new capabilities.

Why a standalone server?

Quarkus already has a built-in Dev MCP server that exposes tools from inside a running application: endpoints, configuration, dev services, testing, and more. So why add another server?

The answer is lifecycle. The built-in Dev MCP server lives inside the Quarkus process. When the app crashes (a compilation error, a missing bean, a bad migration), that MCP server dies with it. The agent loses its connection and cannot inspect what went wrong.

Quarkus Agent MCP runs as a separate process. It wraps quarkus dev as a child process and stays alive when the application crashes. The agent can read the logs, get structured exception details, fix the code, and watch the app recover on its own.

Getting started

Install via JBang with a single command. For Claude Code:

claude mcp add quarkus-agent -- jbang quarkus-agent-mcp@quarkusio

Or as a Claude Code plugin:

claude plugin marketplace add quarkusio/quarkus-agent-mcp
claude plugin install quarkus-agent@quarkus-tools

The README covers configuration for VS Code, Cursor, Windsurf, JetBrains, and other MCP-compatible tools.

Once installed, you can verify it works by asking your agent:

Search the Quarkus docs for how to create a REST endpoint

The agent will use the quarkus_searchDocs tool and return documentation results.

What the agent can do

Quarkus Agent MCP exposes tools organized into five areas.

Create applications

The quarkus_create tool scaffolds a new Quarkus project from natural language. Ask your agent to "create a Quarkus REST API with PostgreSQL and Panache" and it will pick the right extensions, create the project, start it in dev mode, and generate a AGENTS.md — a convention file that AI agents read for project-specific instructions.

Learn before coding: extension skills

Before writing a single line of code, the agent calls quarkus_skills to load coding patterns for the application’s extensions. These skills contain the kind of knowledge that usually lives in a senior developer’s head: which annotations to use, how to write tests, what the common pitfalls are, and troubleshooting guidance.

For example, the Hibernate Validator skill teaches the agent that constraint violations on REST endpoint parameters automatically return HTTP 400, that @Valid is required for cascading validation on nested objects, and that method validation only works on CDI-managed beans.

Without skills, the agent might still produce working code, especially with larger models, but the results become less predictable. Skills level the playing field: even smaller, cheaper models produce correct idiomatic Quarkus code when they have the right patterns to follow.

More on how skills work, and how you can write your own, later in this post.

Search documentation

The quarkus_searchDocs tool performs semantic search over the full Quarkus documentation. On first use, a Docker/Podman container with pre-indexed documentation starts automatically.

The search implementation (currently using BGE embeddings and pgvector) is still being iterated on and may change in future versions. The documentation version matches the project’s Quarkus version, so the agent never gives advice based on a different release.

Manage the application lifecycle

The agent can start, stop, and restart the application. It can check the application status, read logs, and list all managed instances. When the app crashes, the agent uses the Dev MCP proxy to call devui-exceptions_getLastException, which returns the exception class, message, stack trace, and exact source location. It then fixes the code and lets hot reload do the rest.

Proxy to Dev MCP tools

Once the application is running, the agent can discover and call any tool exposed by the built-in Dev MCP server. This includes running tests, listing endpoints, inspecting dev services, changing configuration, and managing extensions, all through a single proxy layer. The tool list is dynamic: when you add or remove extensions, the agent re-discovers the available tools automatically.

The development workflow

Here is what an agent-driven development session looks like in practice:

For a new project:

quarkus_create: scaffold the project, auto-start dev mode
quarkus_skills: learn extension patterns before writing code
quarkus_searchDocs: look up APIs and configuration
Write code and tests
Run tests via quarkus_callTool
If the app crashes, read the exception, fix, and iterate

For an existing project:

quarkus_update: check if the Quarkus version is current
quarkus_start: start dev mode
quarkus_skills: learn extension patterns
Develop, test, iterate

The key insight is skills before code. The agent does not guess at patterns. It reads the skills, then writes code that follows them.

For extension authors: shipping skills with your extension

If you maintain a Quarkus extension, whether in core, Quarkiverse, or your own organization, you can ship a skill file that teaches every AI agent how to use your extension correctly. The agent picks up the skill automatically when a developer adds your extension to their project.

What goes into an extension skill?

A skill file is a Markdown document at META-INF/quarkus-skill.md in your extension’s deployment JAR. It should contain the practical knowledge an agent needs to write correct code with your extension:

Coding patterns: the right way to use your APIs, with brief examples
Testing guidelines: how to write tests that work with your extension
Common pitfalls: mistakes the agent should avoid
Configuration: key properties and their effect

Here is an abbreviated example from the Hibernate Validator extension:

### Bean Validation Annotations

- Use constraints from `jakarta.validation.constraints` packages,
  e.g. `@NotNull`, `@NotBlank`, `@Size`, `@Min`, `@Max`, `@Email`, `@Pattern`
  on class fields and getters or on method parameters of CDI beans.
- Use `@Valid` for cascading validation on nested types.

### REST Integration

- Constraint violations on REST endpoint **parameters** automatically return
  HTTP 400 with validation details.
- Return value validation results in HTTP 500, not 400. Handle
  `ConstraintViolationException` explicitly if you need custom error responses.

### Common Pitfalls

- Do NOT forget `@Valid` on nested object parameters. Without it, constraints
  on nested object fields are silently ignored.
- Method validation only works on CDI-managed beans. Calls on plain `new`
  objects are not validated.

Where to put it

Place the file at:

your-extension/
  deployment/
    src/main/resources/
      META-INF/
        quarkus-skill.md

That is it. When the extension is published and a developer adds it to their project, quarkus_skills will discover the skill from the deployment JAR in the local Maven repository, compose it with metadata from quarkus-extension.yaml, and include any Dev MCP tools your extension exposes.

Per-extension skill discovery from deployment JARs requires Quarkus 3.35.0+. For older versions, the agent will rely on quarkus_searchDocs for guidance instead.

Writing effective skills

Keep these principles in mind:

Be prescriptive, not descriptive. The agent does not need a tour of your API surface; it can read Javadoc for that. It needs to know the right pattern to use and the mistakes to avoid. Instead of "the @Transactional annotation can be used on methods," write "always annotate write operations with @Transactional."

Focus on what surprises people. If every new developer hits the same three issues with your extension, those belong in the skill. If something works exactly as expected, you probably do not need to mention it.

Keep it concise. A skill that is 50 lines of actionable guidance beats 500 lines of documentation rehash. The agent will search the full documentation via quarkus_searchDocs when it needs details. The skill is for the patterns and pitfalls that documentation alone does not prevent.

Include testing patterns. How should tests be written for your extension? What test infrastructure does it provide? This is one of the areas where agents struggle most without guidance.

Test with a cheap model. A large frontier model might produce correct code even without your skill. The real test is whether a smaller, cheaper model (like Haiku or GPT-4o mini) gets it right when following your skill. If it does, your skill is doing its job.

The three-layer composition system

Different teams have different conventions, and sometimes the built-in skill does not cover a specific use case. To handle this, skills use a three-layer composition system:

Extension skill: ships with the extension itself (META-INF/quarkus-skill.md)
User-level skill: stored at ~/.quarkus/skills/<extension-name>/SKILL.md, applies to all projects for that developer
Project-level skill: stored at .agent/skills/<extension-name>/SKILL.md, applies to one project only

Layers 1 and 2 support enhance (append additional guidance) and override (fully replace) composition, controlled by the mode field in the SKILL.md frontmatter:

---
mode: enhance
---

### Our team conventions

- Always use constructor injection, never field injection.
- Name REST resource classes with the `Resource` suffix, not `Controller`.

Project-level skills (layer 3) are standalone files read as-is, with no composition against the base layers. This means any agent can read them directly from the filesystem without needing to understand the composition chain. Use the quarkus_saveSkill tool to materialize a fully composed skill into .agent/skills/, then edit the file directly to customize it for your project.

For global customizations that apply across all projects, the agent can use quarkus_updateSkill to write to ~/.quarkus/skills/.

Privacy

Quarkus Agent MCP runs entirely on your machine. It does not collect telemetry or send data to any third party. Outbound network requests are limited to downloading extension JARs from Maven Central, pulling pre-indexed documentation containers, and checking for Quarkus version updates. Everything is cached locally after the first use.

What is next

Quarkus Agent MCP is part of the DevStar working group and we are actively developing new capabilities. If you are an extension author interested in shipping skills, or a developer with feedback on the workflow, we want to hear from you.

Try it out:

claude mcp add quarkus-agent -- jbang quarkus-agent-mcp@quarkusio

This example uses Claude Code, but any coding agent that supports the MCP protocol (Cursor, Windsurf, GitHub Copilot, JetBrains AI, and others) can connect to Quarkus Agent MCP. See the README for configuration instructions for each agent.

Then ask your agent to build something.

Faster Startup on IBM Semeru with OpenJ9 Shared Classes Cache

Georgios Andrianakis (https://twitter.com/geoand86) — Wed, 06 May 2026 00:00:00 +0000

Slow startup times have long been a challenge for Java applications. Project Leyden addressed this for JVMs like Temurin 25+, which are based on HotSpot, but what about users of JVMs based on IBM OpenJ9 like Semeru?

In our previous post, we described how we integrated Project Leyden into Quarkus, bringing JVM startup way down.

But not everyone runs HotSpot-based JVMs.

Many teams, especially in enterprise environments, run IBM Semeru Runtimes, IBM’s production Java runtime built on the Eclipse OpenJ9 JVM. These teams deserve the similar startup improvements, with the same ease of use.

That’s what we built. Starting with Quarkus 3.35, the same quarkus.package.jar.aot.enabled=true flag that activates Leyden on OpenJDK now automatically generates an OpenJ9 Shared Classes Cache on IBM Semeru.

No code changes. No additional configuration. Quarkus detects the JVM and does the right thing.

What is the OpenJ9 Shared Classes Cache?

The Eclipse OpenJ9 JVM has long offered a feature called Shared Classes Cache (SCC). The concept is similar to what Project Leyden does for HotSpot, but it predates Leyden by many years and goes further in some respects.

At its core, the SCC is a region of shared memory — either a memory-mapped file (persistent) or shared memory segment (non-persistent) — that stores data the JVM would otherwise have to recompute on every startup. When a class is loaded for the first time, OpenJ9 automatically stores it in the cache. On subsequent startups, the JVM finds it there and skips parsing, verification, and loading from disk entirely.

But class data is only the beginning. The SCC stores three categories of data:

Class metadata: Parsed and verified class structures, ready to use without re-reading JAR files.
AOT-compiled native code: The OpenJ9 AOT compiler dynamically compiles Java methods into native code at runtime and stores them in the cache. On subsequent runs, these pre-compiled methods execute immediately instead of being interpreted. The VM automatically selects which methods to AOT-compile using heuristics that identify the startup phase of large applications — no manual configuration needed.
JIT profiling data and compilation hints: The JIT compiler stores profiling information and optimization hints in the cache, allowing subsequent JVM instances to make better compilation decisions from the start. When a cached AOT method runs, the JIT compiler can further optimize it based on actual runtime behavior, giving you the best of both worlds.

The result: significantly faster startup, lower memory overhead during class loading, and a warmer JIT from the very first request.

Unlike other class data sharing implementations, the OpenJ9 SCC is fully dynamic: it is populated transparently as your application runs, without requiring a separate offline step to enumerate classes. The cache is also designed for multi-JVM environments — multiple JVM instances can share the same cache simultaneously, reducing the aggregate memory footprint when running several Java applications on the same host.

If you are familiar with how Leyden works, much of this will sound familiar. The key difference is that SCC is specific to the OpenJ9 JVM and has been production-hardened over many years, while Leyden is a newer effort within OpenJDK targeting HotSpot.

Using it

If you already have quarkus.package.jar.aot.enabled=true in your build, you don’t need to change anything. Just build with a Semeru JDK:

Maven

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

Gradle

./gradlew build quarkusIntTest -Dquarkus.package.jar.aot.enabled=true

That’s it. The build:

Packages your application with the aot-jar format.
Starts the application with -Xshareclasses:name=quarkus-app,cacheDir=app-scc, which tells OpenJ9 to populate the cache as the application runs.
Your @QuarkusIntegrationTest tests run against it, exercising your endpoints and features. During this time, OpenJ9 is continuously populating the cache with class data, AOT-compiled methods, and JIT profiling hints.
When the tests finish and the application shuts down, the app-scc/ directory contains a fully populated Shared Classes Cache.

Once that is done, verify that your logs contain Detected IBM Semeru Runtime - using Shared Classes Cache

To run the application with the cache:

cd target/quarkus-app
java -Xshareclasses:name=quarkus-app,cacheDir=app-scc,readonly -jar quarkus-run.jar

The readonly flag prevents the cache from being modified at runtime. This is the recommended setting for production: the cache is an artifact of the build, not something that should drift in production.

The generated app-scc/ directory must be deployed alongside your JAR:

target/quarkus-app/
├── app-scc/              (1)
├── quarkus-run.jar
├── lib/
└── quarkus/

1	The Shared Classes Cache directory. Its contents are opaque to the user — OpenJ9 manages the internal structure.

Customizing the training run

If you need to pass additional JVM flags during the training run (for example, to increase heap size or enable specific JVM features), you can use:

quarkus.package.jar.aot.additional-recording-args=-Xmx512m

Troubleshooting

If the cache doesn’t seem to improve startup, first verify it is actually being used. Enable verbose output by replacing readonly with readonly,verboseIO:

java -Xshareclasses:name=quarkus-app,cacheDir=app-scc,readonly,verboseIO -jar quarkus-run.jar

This prints detailed information about each class loaded from the cache versus the filesystem.

Also make sure you are using the exact same Semeru JVM version to run the application as was used to build the cache. OpenJ9 uses internal generation numbers to detect incompatible caches; a version mismatch will cause the cache to be ignored.

How auto-detection works

When quarkus.package.jar.aot.enabled=true is set and no explicit type is configured, Quarkus picks the best strategy for the JVM it detects at build time:

Build JVM Strategy Output

Build JVM	Strategy	Output
IBM Semeru	Shared Classes Cache (`-Xshareclasses`)	`app-scc/` directory
HotSpot (25+)	Leyden AOT (`-XX:AOTCache`)	`app.aot` file
Older HotSpot	AppCDS (`-XX:SharedArchiveFile`)	`app-cds.jsa` file

IBM Semeru

Shared Classes Cache (-Xshareclasses)

app-scc/ directory

HotSpot (25+)

Leyden AOT (-XX:AOTCache)

app.aot file

Older HotSpot

AppCDS (-XX:SharedArchiveFile)

app-cds.jsa file

The detection checks java.runtime.name for the string semeru. If it matches, the SCC path is chosen. Otherwise, Quarkus checks the Java version: 25 or higher selects Leyden, anything older falls back to AppCDS.

If you need to override the auto-detection (for example, to force AppCDS on Semeru for comparison), you can set the type explicitly:

quarkus.package.jar.aot.type=SCC

Valid values are AUTO (the default), AOT, AppCDS, and SCC.

One flag, every JVM

This is the design decision we are most proud of in this work. Your build configuration, CI pipeline, and Dockerfile don’t need to know which JVM will run the application. Set quarkus.package.jar.aot.enabled=true, and the build adapts.

This matters in practice. Teams that standardize on Semeru for some services and HotSpot for others can use the same Quarkus build configuration everywhere. Switching JVMs doesn’t require touching application.properties.

It also means that the Quarkus documentation, guides, and examples work the same way regardless of the JVM. When we write "enable AOT for faster startup," that statement is true whether you run HotSpot, Semeru, or an older JDK.

Differences from Project Leyden

While the user experience is intentionally identical, there are a few technical differences worth noting:

Project Leyden (HotSpot) Shared Classes Cache (OpenJ9)

	Project Leyden (HotSpot)	Shared Classes Cache (OpenJ9)
Cache format	Single `app.aot` file	`app-scc/` directory
What is cached	Loaded/linked classes, method profiles (future: JIT code)	Class data, AOT-compiled native code, JIT profiling data and hints
AOT compilation	Not yet included (planned for future JDK releases)	Included: startup methods are AOT-compiled and stored in the cache
Training	Two-step: record configuration, then create cache in a separate JVM invocation	Single step: cache is populated during the training run itself
JVM requirement	Version >=25	Any IBM Semeru version
Maturity	New (JDK 25, actively evolving)	Mature (production-hardened over many years in OpenJ9)

Cache format

Single app.aot file

app-scc/ directory

What is cached

Loaded/linked classes, method profiles (future: JIT code)

Class data, AOT-compiled native code, JIT profiling data and hints

AOT compilation

Not yet included (planned for future JDK releases)

Included: startup methods are AOT-compiled and stored in the cache

Training

Two-step: record configuration, then create cache in a separate JVM invocation

Single step: cache is populated during the training run itself

JVM requirement

Version >=25

Any IBM Semeru version

Maturity

New (JDK 25, actively evolving)

Mature (production-hardened over many years in OpenJ9)

One notable difference is that the SCC already includes AOT-compiled native code for startup methods, whereas Leyden currently caches class loading and linking data plus method profiling information, with compiled code storage planned for future JDK versions.

Some numbers

To give you a sense of what the SCC brings in practice, we measured startup time and memory usage for the Quarkus REST JSON quickstart application on IBM Semeru 25, with and without the Shared Classes Cache.

Startup time Diff RSS Diff

	Startup time	Diff	RSS	Diff
Default (no SCC)	`433 ms`	`Reference`	`107 MB`	`Reference`
With Shared Classes Cache	`206 ms`	`-52%`	`87 MB`	`-19%`

Default (no SCC)

433 ms

Reference

107 MB

Reference

With Shared Classes Cache

206 ms

-52%

87 MB

-19%

The SCC file is 25 MB in size — a reasonable cost for a 52% startup improvement.

These numbers were measured on a developer laptop, not in an isolated lab environment. Your results will vary depending on your application’s size and complexity. The more classes and methods your application loads during startup, the more the SCC helps.

We were able to start a Quarkus REST application on IBM Semeru in just 206 ms — and this is on the JVM, with full JIT compilation, full debugging support, and no native image involved.

Container images and future work

Manual deployment today

Today, you can deploy a Quarkus application with a pre-built SCC by copying the app-scc/ directory into your container image:

FROM icr.io/appcafe/ibm-semeru-runtimes:open-21-jre-ubi-minimal
COPY target/quarkus-app /deployments
WORKDIR /deployments
CMD ["java", \
     "-Xshareclasses:name=quarkus-app,cacheDir=app-scc,readonly", \
     "-jar", "quarkus-run.jar"]

This works, but it has a limitation: the SCC must be generated on the same JVM version that will run in the container. If your build JVM differs from the container’s JVM, the cache will be ignored. To ensure a match, generate the cache using the same Semeru image in your CI pipeline.

Automated container image integration

The container image integration we described in the Leyden post — where Quarkus produces an AOT-optimized container image in a single command — is currently specific to the Leyden AOT path. Extending it to support SCC-based container images is on our roadmap.

Cache layering for Docker

This is where things get particularly interesting. OpenJ9’s SCC supports multi-layer caches, a feature specifically designed for container environments.

The problem with a single monolithic cache in a container image is Docker’s copy-on-write mechanism. If a base image contains a populated SCC and a higher layer writes to it (to add application-specific data), Docker duplicates the entire cache into the new layer. This defeats the purpose of layer sharing and inflates the image size.

OpenJ9 solves this with the -Xshareclasses:createLayer option. Instead of a single cache, you build a stack of cache layers that align with your container image layers:

Layer 0 (JDK base image): cache populated with JDK and framework classes.
Layer 1 (application image): a separate, smaller cache layer containing only the application-specific class data, AOT code, and JIT hints.

Each cache layer is sized individually for its content, and the JVM reads from all layers at startup. Because lower layers are never modified by higher ones, Docker’s layer sharing works correctly — teams using the same base image share the JDK cache layer across all their application images.

This is the part we are most excited about for future work. We plan to integrate this layered approach into Quarkus’s container image extensions (quarkus-container-image-docker, quarkus-container-image-podman, and quarkus-container-image-jib). The goal is the same one-command experience we built for Leyden:

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

This would produce a container image with a properly layered SCC — the framework cache in a shared base layer, the application-specific cache in the top layer — optimized for both startup time and image size.

In microservices architectures where multiple Quarkus services share the same base image and dependency set, this layering could significantly reduce the total storage and transfer cost across all service images.

Acknowledgements

We would like to thank the OpenJDK team at IBM for their collaboration. The discussions around Leyden and Semeru’s shared classes technology were instrumental in shaping this integration.

Conclusion

The beauty of this integration is its simplicity: one flag, multiple JVMs, optimal performance everywhere. Whether you’re running HotSpot or Semeru, Quarkus has you covered, as Quarkus has always been about meeting developers where they are.

We will continue tracking developments in both Project Leyden and OpenJ9 to bring you the best performance on whatever platform you choose.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on Stack Overflow.

Emergency releases to fix CVE-2026-39852 in all supported streams

Jan Martiška (https://twitter.com/janmartiska) — Mon, 04 May 2026 00:00:00 +0000

Today, we published releases to fix a severe security vulnerability: CVE-2026-39852 in all supported streams. The patched versions are:

3.20.6.1
3.27.3.1
3.33.1.1
3.34.7
3.35.2

Update

Please make sure you update to one of these releases immediately. To update, we recommend updating to the latest version of the Quarkus CLI and run:

quarkus update

Quarkus 3.35 - JAR tree-shaking, PGO for native, Semeru AOT, @Transactional for Hibernate Reactive, and more

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

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

This release brings several notable features:

#53295 - JAR tree-shaking to eliminate unused classes
#53278 - Profile-Guided Optimization (PGO) support for native builds
#53339 - Semeru AOT support
#51063 - Support @Transactional for Hibernate Reactive
#53432 - CORS support for the management interface
#52919 - Remove the use of System Properties to propagate configuration in tests
New snapshot distribution infrastructure

Update

To update to Quarkus 3.35, 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.35.

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

What’s new?

JAR tree-shaking

A new experimental quarkus.package.jar.tree-shake.mode option enables build-time dependency tree-shaking. When set to classes, Quarkus performs bytecode reachability analysis to identify and exclude unused classes from runtime dependencies, reducing application JAR size.

The analysis traces references through supertypes, annotations, ServiceLoader entries, reflective class loading, and more.

As an example, running tree-shaking on the Quarkus CLI removes over 6,000 unreachable classes, saving around 18 MB (39.5%).

This feature supports fast-jar, uber-jar, legacy-jar, and aot-jar packaging types.

As mentioned, this new feature is experimental, and feedback is highly welcome!

Profile-guided optimization for native builds

You can now opt in to Profile-Guided Optimization (PGO) for native builds by setting quarkus.native.pgo.enabled=true.

Note that PGO is a feature of Oracle GraalVM and is not available in GraalVM Community Edition.

When enabled, Quarkus uses your integration tests as the workload to profile the application. The resulting PGO data is then fed into the native compilation for better runtime performance.

The implementation follows a similar pattern to the Project Leyden AOT support introduced in Quarkus 3.32.

Semeru AOT support

Building on the Project Leyden AOT integration from Quarkus 3.32, Quarkus now also supports IBM Semeru’s AOT features.

In initial testing on the rest-json quickstart with IBM Semeru Runtime Open Edition 25, startup time was cut roughly in half (from ~380 ms down to ~190 ms).

For now, this is limited to building JARs with Semeru AOT, automatic container image building (as available with Leyden) is not yet supported.

`@Transactional` for Hibernate Reactive

Quarkus now supports the @Transactional annotation for Hibernate Reactive, thanks to a new quarkus-reactive-transactions extension.

This means you can use the familiar @Transactional annotation on methods that return Uni, and the transaction lifecycle (begin, commit, rollback) will be managed within the reactive pipeline.

A few things to keep in mind:

Only TxType.REQUIRED is currently supported.
Mixing @Transactional with @WithTransaction or @WithSessionOnDemand is not allowed.
Methods annotated with @Transactional are no longer automatically considered @Blocking. If your method is blocking but returns Uni, you now need an explicit @Blocking annotation. See the migration guide for details.

CORS support for the management interface

The management interface now has its own dedicated CORS configuration, allowing you to set CORS policies independently from the main HTTP interface.

Testing improvements

The test infrastructure no longer uses System Properties to propagate configuration from Dev Services, Test Resources, and Test Profiles. This change opens the door for better parallel test execution (which we hope to achieve at some point in the future) and makes the Config system truly immutable.

Tests using QuarkusDevModeTest, QuarkusIntegrationTest, or QuarkusMainIntegrationTest can now declare a Config field or method parameter to access the updated configuration.

New snapshot distribution

Quarkus snapshots are no longer published to Sonatype, which had reliability issues with the volume of artifacts involved. Snapshots are now published daily as GitHub Releases in the quarkusio/quarkus-ecosystem-ci repository, with version 999-SNAPSHOT. Each release contains a maven-repo.tar.gz asset with pre-built Maven artifacts that you can extract into your local Maven repository.

For CI setups, a dedicated GitHub Action is also available.

More details can be found in the Using snapshots section of the contributing guide.

Jackson reflection-free serializers for Quarkus REST

We initially planned to make Jackson reflection-free serializers the default for Quarkus REST in 3.35. However, thanks to several community members who tested this feature and reported issues, we identified a number of edge cases that still need to be addressed. We decided to postpone making it the default to 3.36, so that we can fix these issues first.

We are very grateful to everyone who took the time to report problems, your feedback is what makes Quarkus better.

In the meantime, we very much welcome more testing from our community. You can enable reflection-free serializers by adding the following property to your configuration:

quarkus.rest.jackson.optimization.enable-reflection-free-serializers=true

Please report any issues you encounter on GitHub.

Platform updates

Various Platform components were upgraded including:

Camel Quarkus to 3.35.0
Quarkus CXF to 3.35.1 - see release notes for 3.35.0 and 3.35.1
Quarkus Amazon Services to 3.18.0
Quarkus MCP Server to 1.12.0
Quarkus Flow to 0.9.0

Full changelog

You can get the full changelog of 3.35.0.CR1, 3.35.0, and 3.35.1 on GitHub.

Contributors

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

In particular for the 3.35 release, thanks to Ales Justin, Alexey Loubyansky, andreatp, Andy Damevin, anuragg-saxenaa, Arseni Buinitski, Aurea Munoz, Aurélien Pupier, Bruno Baptista, brunobat, Carles Arnal, Cesar M. Romero-Pedraza, Chris Laprun, Chris Ruffalo, Clement Escoffier, Cristiano Nicolai, DerFrZocker, Dmitri Bourlatchkov, Faisal Dilawar, Foivos Zakkak, George Gastaldi, Georgios Andrianakis, Guillaume Smet, Holly Cummins, Inaki Villar, Jakub Jedlicka, Jamal Dabari, Jan Martiska, Jens Teglhus Møller, Julien Ponge, Karm Michal Babacek, Katia Aresti, keshavprashatdeshpande, Ladislav Thon, lberrymage, Luca Molteni, marco sappe griot, mariofusco, marko-bekhta, Martin Kouba, Matej Novotny, Matej Vašek, Max Rydahl Andersen, Maximilian Zellhofer, Melloware, Michael Edgar, Michal Maléř, Michal Vavřík, Mihajlo Veljković, Nick Robison, Nico Hinrichs, Ozan Gunalp, Paramvir Jindal, Phillip Kruger, Phillip Krüger, PreetiYadav, Robert Toyonaga, Roberto Cortez, Rolfe Dlugy-Hegwer, Rostislav Svoboda, Sergey Beryozkin, Simon Scatton, Simon Scholz, Stéphane Épardaud, Teymur Babayev, Thomas Segismont, tiwari91, Tiziano Basile, tom, xstefank, Yoann Rodière, and Yoshikazu Nojima.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on Stack Overflow.

A2A Java SDK 1.0.0.Beta1 Released

Emmanuel Hugonnet (https://twitter.com/ehsavoie) — Mon, 27 Apr 2026 00:00:00 +0000

We are pleased to announce the release of A2A Java SDK 1.0.0.Beta1, our first release fully aligned with the final A2A Specification 1.0.0. The A2A Protocol has reached stability as an open standard, and this release marks the Java SDK tracking that maturity: protocol conformance is the central focus, and the SDK coordinates now reflect the project’s identity under the A2A Project organization.

As a sign of this maturity, two structural breaking changes accompany this release:

Java packages have been renamed from io.a2a. to org.a2aproject.sdk.
The Maven groupId has changed from io.github.a2asdk to org.a2aproject.sdk (first introduced in 1.0.0.Alpha4)

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.

Breaking Changes

New Maven Coordinates

The Maven groupId has changed from io.github.a2asdk to org.a2aproject.sdk. If you are upgrading from any previous release, you must update your build files accordingly.

The root artifact coordinates were renamed to reflect the project’s new home under the A2A Project organization and its availability on Maven Central.

Update your pom.xml dependencies accordingly:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.a2aproject.sdk</groupId>
            <artifactId>a2a-java-sdk-bom</artifactId>
            <version>1.0.0.Beta1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<!-- Client -->
<dependency>
    <groupId>org.a2aproject.sdk</groupId>
    <artifactId>a2a-java-sdk-client</artifactId>
</dependency>

<!-- For JSON-RPC transport -->
<dependency>
    <groupId>org.a2aproject.sdk</groupId>
    <artifactId>a2a-java-sdk-reference-jsonrpc</artifactId>
</dependency>

<!-- For gRPC transport -->
<dependency>
    <groupId>org.a2aproject.sdk</groupId>
    <artifactId>a2a-java-sdk-reference-grpc</artifactId>
</dependency>

<!-- For HTTP+JSON/REST transport -->
<dependency>
    <groupId>org.a2aproject.sdk</groupId>
    <artifactId>a2a-java-sdk-reference-rest</artifactId>
</dependency>

New Java Package Names

All Java packages have been renamed from io.a2a. to org.a2aproject.sdk.. You must update all import statements in your source code when upgrading from any previous release.

For example:

// Before
import io.a2a.client.A2AClient;
import io.a2a.model.Task;

// After
import org.a2aproject.sdk.client.A2AClient;
import org.a2aproject.sdk.model.Task;

Most IDEs can automate this migration via a project-wide find-and-replace of io.a2a → org.a2aproject.sdk in import statements, or by using the "Optimize Imports" / "Migrate" refactoring tools.

Key Highlights in 1.0.0.Beta1

Equal Transport Support

All three transports — JSON-RPC, gRPC, and HTTP+JSON/REST — are now fully supported and considered equal. Simply add the dependency for the transport you need (a2a-java-sdk-reference-jsonrpc, a2a-java-sdk-reference-grpc, or a2a-java-sdk-reference-rest) and the SDK will work seamlessly regardless of your choice.

Structured Error Codes and Details

A2A error types now carry structured error codes and details, making error handling more precise and easier to integrate with observability tooling. Error responses also now use the correct data field name (previously details) in JSON/HTTP responses, in alignment with the specification.

HTTP Caching Headers for Agent Card

The Agent Card endpoint now returns proper HTTP caching headers, allowing clients and proxies to cache agent metadata efficiently and reduce unnecessary round trips.

`DataPart.fromJson()` Factory Method

A new DataPart.fromJson() factory method makes it straightforward to construct a DataPart from a raw JSON string, without requiring prior deserialization.

Flexible HTTP Client Support

The SDK defaults to a JdkA2AHttpClient backed by the standard JDK HttpClient, suitable for any Java environment. The HttpClient builder also supports constructing a JdkA2AHttpClient from a prebuilt HttpClient instance, enabling advanced configuration scenarios such as custom SSL contexts or connection pool tuning.

When running on Quarkus, you can instead use the VertxA2AHttpClient, which is backed by the Vert.x HTTP client for better integration with Quarkus’s reactive engine, connection management, and observability features.

Bug Fixes and Stability

Terminal-state tasks now correctly reject further operations with UnsupportedOperationError
Race conditions in EventConsumer and the SSE transport have been resolved
PushNotificationNotSupportedError now returns HTTP 501 as required by the specification
POST requests without a Content-Type header are now accepted when the body is empty
Tenant and protocolVersion are now correctly preserved in the ClientBuilder

What’s Next: Road to 1.0.0.GA

Before the 1.0.0.GA release, we plan to introduce the following:

Cross-version protocol support: the SDK will be able to handle both version 1.0.0 and 0.3.0 of the A2A Protocol simultaneously, making it easier to interoperate with agents built against earlier versions of the specification.
Specification micro-update tracking: as the A2A Specification evolves with patch-level updates, the SDK will follow those changes promptly to remain fully conformant.

Contributors

This release was made possible by the work of seven contributors. A special thank you to our four first-time contributors:

And to the returning contributors:

Thank you all for your code, reviews, and feedback!

Resources

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are an A2A Java SDK user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on Discord;

Quarkus 3.34.6 - Maintenance release

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

Today, we released Quarkus 3.34.6, the last maintenance release for our 3.34 stream.

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.

Full changelog

You can get the full changelog of 3.34.6 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on Stack Overflow.

Quarkus Newsletter #67 - April

James Cobb (https://twitter.com/insectengine) — Wed, 22 Apr 2026 00:00:00 +0000

Read "Build a Streaming AI Chat in Java with Quarkus, Vaadin, and LangChain4j", a hands-on guest post by Sebastian Kühnau showing how to stream LLM responses token by token in a pure Java UI with Vaadin Flow and Quarkus. Check out Mario Fusco’s post to learn our reasoning behind enabling by default in the Quarkus 3.35 release. Scivics Lab wrote a post "quarkus-chat-ui: A Web Front-End for LLMs, and a Real-World Case for POJO-actor" that introduces a new Chat UI component built with Vaadin and designed to integrate seamlessly into a Quarkus application, simplifying the creation of conversational interfaces. They then follow with another "quarkus-chat-ui (2): The Actor Design Behind LLM-to-LLM Conversation" so you can see how to actually use POJO-actor in quarkus-chat-ui, a Quarkus-based LLM chat UI that connects to Claude Code CLI, vLLM, and other backends. Learn how to integrate Redis caching and data storage in a Quarkus Java application using the Quarkus Redis extension with reactive by reading "How to Use Redis with Quarkus in Java" by Nawaz Dhandala. Markus Eisele wrote "AI Coding Tools in 2026: How to Work With Agents Without Losing Control" a Java engineer’s operating model: Ask/Plan/Code flows, guardrails, and review discipline at scale.

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

Check out Newsletter #67: April!

Want to get newsletters in your inbox? Sign up for the newsletter using the on page form.

Quarkus 3.34.5 - Maintenance release

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

Today, we released Quarkus 3.34.5, the third maintenance release for our 3.34 stream (we skipped 3.34.4, due to a regression detected late in the Platform, caused by a Kafka Clients update).

Atualização

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.

Full changelog

You can get the full changelog of 3.34.4 and 3.34.5 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on Stack Overflow.

Enabling reflection-free Jackson serializers by default

Mario Fusco (https://twitter.com/mariofusco) — Mon, 13 Apr 2026 00:00:00 +0000

Some time ago, we started experimenting on how to improve the efficiency of JSON serialization and deserialization offered by Jackson and extensively used in Quarkus applications. From a performance point of view, Jackson’s main bottleneck is its heavy reliance on Java reflection to access or populate data objects at runtime. To address this issue, we developed a build-time metaprogramming approach that generates reflection-free serializers and deserializers for Jackson.

In this article we explained how we implemented this feature in Quarkus and the performance improvements it brings. Since then, we have been continuously working to enhance this feature, fix bugs, and improve compatibility with various Jackson features.

Configuring reflection-free Jackson serialization

Given the experimental nature of this feature, we initially made it opt-in. To enable reflection-free Jackson serializers and deserializers in your Quarkus application, it is necessary to add the following configuration to your application.properties file:

quarkus.rest.jackson.optimization.enable-reflection-free-serializers=true

In the past months an increasing number of users have tried this feature, taking advantage of the performance benefits it offers, but also helping us to discover bugs, edge cases, and compatibility issues with various Jackson features that we have addressed one by one. Overall, we have received positive feedback from the community, so we have decided to make the obvious next step.

Enabling by default in the Quarkus 3.35 release

At the moment the entire Quarkus test suite is passing with this feature enabled, and we have addressed all compatibility issues reported by users so far. Therefore, we have decided to enable this feature by default in the next Quarkus 3.35 release.

In order to cover the broadest possible range of use cases, we invite you to test your applications with this feature enabled, possibly also measuring its impact on performances. If you encounter any issues or have feedback, please report them on our GitHub repository or reach out to us on the Quarkus community channels. This will help us to be more confident about the stability of this feature and ensure a smooth transition for all users.

Quarkus 3.34.3 - Maintenance release

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

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

Atualização

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.

Full changelog

You can get the full changelog of 3.34.3 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on Stack Overflow.

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).

Atualização

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.

Full changelog

You can get the full changelog of 3.34.2 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Atualização

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.

Full changelog

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

Contributors

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.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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:

Atualização

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.

What’s new?

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

Full changelog

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.

Contributors

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.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Atualização

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.

Full changelog

You can get the full changelog of 3.27.3 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Atualização

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.

Full changelog

You can get the full changelog of 3.20.6 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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!

Want to get newsletters in your inbox? Sign up for the newsletter using the on page form.

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.

Atualização

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.

Full changelog

You can get the full changelog of 3.32.3 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Atualização

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.

Full changelog

You can get the full changelog of 3.32.2 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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`	`Reference`	`456 MB`	`Reference`	`122 MB`	`Reference`
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

Reference

456 MB

Reference

122 MB

Reference

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`	`Reference`	`517 MB`	`Reference`	`580 MB`	`Reference`
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

Reference

517 MB

Reference

580 MB

Reference

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.

Conclusion

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.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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 a 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 rolling 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.

Atualização

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.

What’s new?

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.

Segurança

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.

Full changelog

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

Contributors

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.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Conclusion

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!

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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!

Características

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))

Conclusion

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

Referências

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).

Atualização

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 changelog

You can get the full changelog of 3.31.4 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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!

Want to get newsletters in your inbox? Sign up for the newsletter using the on page form.

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?

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

Migration Guide

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.

Primeiros passos

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>

Resources

Conclusion

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).

Atualização

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 changelog

You can get the full changelog of 3.31.3 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Conclusion

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).

Atualização

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 changelog

You can get the full changelog of 3.31.2 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Atualização

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.

What’s new?

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

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.

Segurança

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.

Full changelog

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

Contributors

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.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Atualização

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.

Full changelog

You can get the full changelog of 3.30.8 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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!

Atualização

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.

Full changelog

You can get the full changelog of 3.30.7 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Atualização

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.

Full changelog

You can get the full changelog of 3.27.2 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Atualização

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.

Full changelog

You can get the full changelog of 3.20.5 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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

Primeiros passos

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!

Want to get newsletters in your inbox? Sign up for the newsletter using the on page form.

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.

Conclusion

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.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Atualização

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.

Full changelog

You can get the full changelog of 3.30.6 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Background

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.

For example,

    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.

For example,

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.

In general, the Quarkus philosophy is to move work from application start to build-time, not the other way round. If you do need to move work into a postStartHook or recorder, try to move as little as possible, to avoid negative performance impacts. Often, code needs to know that a Dev Service will be created, but not the actual address. This can be handled as part of the normal build flow using a marker build item, leaving the bare minimum to execute as part of the hook.

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.

Exemplos

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!

Atualização

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.

Full changelog

You can get the full changelog of 3.30.5 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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:

public class Code {

    // 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.

Atualização

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.

Full changelog

You can get the full changelog of 3.30.4 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Conclusion

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!

Want to get newsletters in your inbox? Sign up for the newsletter using the on page form.

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.

Atualização

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.

Full changelog

You can get the full changelog of 3.30.3 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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.

Atualização

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.

Full changelog

You can get the full changelog of 3.30.2 on GitHub.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on 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:

Segurança

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.

Conclusion

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.

Atualização

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.

What’s new?

REST Client

@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.

CLI

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.

Full changelog

You can get the full changelog of 3.30.0.CR1, 3.30.0, and 3.30.1 on GitHub.

Contributors

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.

Come Join Us

We value your feedback a lot so please report bugs, ask for improvements… Let’s build something great together!

If you are a Quarkus user or just curious, don’t be shy and join our welcoming community:

provide feedback on GitHub;
craft some code and push a PR;
discuss with us on Zulip and on the mailing list;
ask your questions on Stack Overflow.

Quarkus

Introducing Quarkus Agent MCP: teaching AI agents to speak Quarkus

What is MCP?

Why a standalone server?

Getting started

What the agent can do

Create applications

Learn before coding: extension skills

Search documentation

Manage the application lifecycle

Proxy to Dev MCP tools

The development workflow

For extension authors: shipping skills with your extension

What goes into an extension skill?

Where to put it

Writing effective skills

The three-layer composition system

Privacy

What is next

Faster Startup on IBM Semeru with OpenJ9 Shared Classes Cache

What is the OpenJ9 Shared Classes Cache?

Using it

Customizing the training run

Troubleshooting

How auto-detection works

One flag, every JVM

Differences from Project Leyden

Some numbers

Container images and future work

Manual deployment today

Automated container image integration

Cache layering for Docker

Acknowledgements

Conclusion

Come Join Us

Emergency releases to fix CVE-2026-39852 in all supported streams

Update

Quarkus 3.35 - JAR tree-shaking, PGO for native, Semeru AOT, @Transactional for Hibernate Reactive, and more

Update

What’s new?

JAR tree-shaking

Profile-guided optimization for native builds

Semeru AOT support

@Transactional for Hibernate Reactive

CORS support for the management interface

Testing improvements

New snapshot distribution

Jackson reflection-free serializers for Quarkus REST

Platform updates

Full changelog

Contributors

Come Join Us

A2A Java SDK 1.0.0.Beta1 Released

What’s A2A?

Breaking Changes

New Maven Coordinates

New Java Package Names

Key Highlights in 1.0.0.Beta1

Equal Transport Support

Structured Error Codes and Details

HTTP Caching Headers for Agent Card

DataPart.fromJson() Factory Method

Flexible HTTP Client Support

Bug Fixes and Stability

What’s Next: Road to 1.0.0.GA

Contributors

Resources

Come Join Us

Quarkus 3.34.6 - Maintenance release

Update

Full changelog

Come Join Us

Quarkus Newsletter #67 - April

Quarkus 3.34.5 - Maintenance release

Atualização

Full changelog

Come Join Us

Enabling reflection-free Jackson serializers by default

Configuring reflection-free Jackson serialization

Enabling by default in the Quarkus 3.35 release

`@Transactional` for Hibernate Reactive

`DataPart.fromJson()` Factory Method