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.

はじめに

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:

クラスメタデータ: 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

トラブルシューティング

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.

いくつかの数値

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.

起動時間差分 RSS 差分

	起動時間	差分	RSS	差分
Default (no SCC)	`433 ms`	`参考`	`107 MB`	`参考`
With Shared Classes Cache	`206 ms`	`-52%`	`87 MB`	`-19%`

Default (no SCC)

433 ms

参考

107 MB

参考

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.

謝辞

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.

まとめ

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.

参加のお誘い

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

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

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
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.

変更点

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.

プラットフォームの更新

様々なプラットフォームコンポーネントがアップグレードされました。以下が含まれます。

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

完全な変更ログ

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

コントリビューター

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.

参加のお誘い

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

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
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)

A2A とは？

Agent2Agent (A2A) プロトコルは、基盤となるフレームワーク、言語、ベンダーに関係なく、AI エージェント同士が通信し、連携できるようにするためのオープンスタンダードです。A2A Java SDK を使用すると、Quarkus ベースのリファレンス実装を使用して、A2A 準拠のエージェントを Java で簡単に構築できます。

破壊的変更

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.

例えば、以下のようになります:

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

コントリビューター

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!

リソース

参加のお誘い

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

Quarkus 3.34 に更新するには、最新バージョンの Quarkus CLI に更新し、次を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.34 にアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.34 移行ガイドを参照してください。

完全な変更履歴

You can get the full changelog of 3.34.6 on GitHub.

参加のお誘い

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

GitHub でフィードバック
コードを作成し、プルリクエストを送信
Zulip やメーリングリストでディスカッションに参加
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.

最新のQuarkus Insightsエピソード、トップツイート/ディスカッション、今後開催されるQuarkus参加イベントもご覧いただけます。

Check out Newsletter #67: April!

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

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

Update

Quarkus 3.34 に更新するには、最新バージョンの Quarkus CLI に更新し、次を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.34 にアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.34 移行ガイドを参照してください。

完全な変更ログ

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

参加のお誘い

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

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

リフレクションなしの Jackson シリアライザーをデフォルトで有効にする

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

以前から、Jackson が提供し、Quarkus アプリケーションで広く使用されている JSON のシリアル化とデシリアル化の効率を改善する方法を試してきました。パフォーマンスの観点から見ると、Jackson の主なボトルネックは、実行時にデータオブジェクトにアクセスしたり、データを入力したりするために Java のリフレクションに大きく依存していることです。この問題に対処するため、Jackson 向けにリフレクションなしのシリアライザーとデシリアライザーを生成するビルド時メタプログラミングアプローチを開発しました。

この記事で、Quarkus でこの機能をどのように実装したか、そしてそれによってもたらされるパフォーマンスの改善について説明しました。それ以来、私たちはこの機能を強化し、バグを修正し、さまざまな Jackson 機能との互換性を改善するために継続的に取り組んできました。

リフレクションなしの Jackson シリアル化の設定

この機能は実験的な性質であったため、当初はオプトイン方式にしていました。Quarkus アプリケーションでリフレクションなしの Jackson シリアライザーとデシリアライザーを有効にするには、application.properties ファイルに次の設定を追加する必要がありました。

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

ここ数カ月、この機能を試すユーザーが増え、提供されるパフォーマンス上の利点を活用するだけでなく、バグ、エッジケース、さまざまな Jackson 機能との互換性の問題を発見するのに役立ってくれました。これらは一つずつ対処してきました。全体として、コミュニティーから肯定的なフィードバックをいただいているため、次の明白なステップを踏むことを決定しました。

Quarkus 3.35 リリースでデフォルトで有効化

現時点では、Quarkus のテストスイート全体がこの機能を有効にした状態でパスしており、これまでユーザーから報告されたすべての互換性の問題に対処しました。したがって、次の Quarkus 3.35 リリースでは、この機能をデフォルトで有効にすることに決定しました。

可能な限り幅広いユースケースをカバーするために、この機能を有効にした状態でアプリケーションをテストし、できればパフォーマンスへの影響も測定していただくようお願いします。問題に遭遇した場合やフィードバックがある場合は、GitHub リポジトリーに報告するか、Quarkus コミュニティーチャネルでお知らせください。これは、この機能の安定性についてより確信を持ち、すべてのユーザーにスムーズな移行を保証するのに役立ちます。

Quarkus 3.34.3 - メンテナンスリリース

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

本日、3.34ストリーム向けの2番目のメンテナンスリリースである Quarkus 3.34.3 をリリースしました (3.34.0はスキップしました)。

Update

Quarkus 3.34 にアップデートするには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.34 へアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.34 移行ガイドを参照してください。

完全な変更ログ

3.34.3 の完全なチェンジログは GitHub で確認できます。

参加のお誘い

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

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

Quarkus 3.34.2 - メンテナンスリリース

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

本日、Quarkus 3.34.2 をリリースしました。これは、3.34 ストリーム初のメンテナンスリリースです (3.34.0 はスキップされました)。

Update

Quarkus 3.34 にアップデートするには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします:

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.34 へアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.34 移行ガイドを参照してください。

完全な変更履歴

完全な変更履歴は、 3.34.2 の GitHub で確認できます。

参加のお誘い

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

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

Quarkus 3.34 - 全体的な機能強化

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

本日、 Quarkus 3.33 LTS と Quarkus 3.34 の両方をリリースしました。

Quarkus 3.33 は、Quarkus 3.32 から分岐し、12 か月間メンテナンスされる Long Term Support (LTS) リリースですが、 Quarkus 3.34 には、全体的に多くの機能強化が施されています。 Dev UI、Panache Next、その他多くの領域が改善されました。

このリリースには、将来のバージョンで実を結ぶ内部的な変更とリファクタリングも含まれています。

Update

Quarkus 3.34 に更新するには、最新バージョンの Quarkus CLI に更新し、次を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.34 にアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.34 移行ガイドを参照してください。

完全な変更履歴

3.34.0.CR1 、 3.34.0 、および 3.34.1 の完全な変更履歴を GitHub で確認できます。

コントリビューター

Quarkus コミュニティーは成長しており、現在 1173 人の貢献者がいます。貢献者全員に心から感謝いたします。

特に 3.34 リリースに関しては、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、Yoann Rodière の各氏に感謝いたします。

参加のお誘い

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

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

Quarkus 3.33 LTS - 新しいLTSバージョン

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

このたび、Quarkusの新しいLTS (Long Term Support) バージョンであるQuarkus 3.33のリリースを発表できることを大変嬉しく思います。

このバージョンはQuarkus 3.32をベースに構築されています。本日リリースされた Quarkus 3.34 には新しい機能が導入されています。

LTSポリシーについて詳しく知りたい場合は、 LTSに関する発表を必ずお読みください。

LTSリリースは12ヶ月間サポートされます。

前回のLTSであるQuarkus 3.27 LTSから移行される場合、多くのエキサイティングな新機能がありますので、以下の発表をお読みになることをお勧めします。

Update

Quarkus 3.33 LTSにアップデートするには、Quarkus CLIを最新バージョンに更新して、以下を実行することをお勧めします。

quarkus update

quarkus update コマンドは、Quarkusの任意のバージョン（2.xを含む）からQuarkus 3.33 LTSにアプリケーションを更新できることに注意してください。

3.32からアップグレードする場合、3.33 LTSは3.32の直接的な継続であるため、何もする必要はありません。

以前のLTSであるQuarkus 3.27 LTSからアップグレードする場合は、以下の移行ガイドを参照してください。

3.28の移行ガイド
3.29の移行ガイド
3.30の移行ガイド
3.31の移行ガイド
3.32の移行ガイド
3.33の移行ガイド - 3.33は3.32の継続であるため、このガイドは空です

quarkus update コマンドはほとんどの面倒な作業を処理するはずですが、手動で処理する必要があるケースもまだありますので、これらの移行ガイドを注意深く読むことをお勧めします。

変更点

プラットフォームコンポーネントのアップグレード

様々なプラットフォームコンポーネントがアップグレードされました。以下が含まれます。

Quarkus CXF を 3.33.0 に - リリースノートを参照
Camel Quarkus を 3.33.0 に
Quarkus Operator SDK を 7.7.3 に
Quarkus Vault を 4.7.0 に
Quarkus Qpid JMS を 2.12.0 に

完全な変更履歴

Quarkus 3.33 LTSのコア部分はQuarkus 3.32をベースとしており、3.33.1に含まれるいくつかの追加修正が適用されています。

3.33.1 の完全な変更履歴はGitHubで確認できます。

コントリビューター

Quarkusコミュニティは成長を続けており、現在 1173人のコントリビューターがいます。皆様に心から感謝いたします。

特に3.33リリースの貢献者として、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、およびYoann Rodièreに感謝いたします。

3.33 LTSは3.32のバグ修正のみを含んでいるため、リストは通常より少し短くなっています。

参加のお誘い

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

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

Quarkus 3.27.3 がリリースされました - LTS メンテナンスリリース

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

本日、Quarkus 3.27.3 をリリースしました。これは 3.27 LTS ストリームの次のメンテナンスリリースです。

このリリースには、バグ修正、ドキュメントの更新、および以下の CVE に対する修正が含まれています:

すでに 3.27 を使用している方にとって、安全なアップグレードとなるはずです。

Update

Quarkus 3.27 に更新するには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします:

quarkus update --stream=3.27

なお、quarkus update を使用すると、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.27 にアプリケーションを更新できます。

完全な変更履歴

以下から GitHub で 3.27.3 の完全な変更履歴を取得できます。

参加のお誘い

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

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

Quarkus 3.20.6 リリース - LTS メンテナンスリリース

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

本日、Quarkus 3.20.6 をリリースしました。これは 3.20 LTS ストリームの次期メンテナンスリリースです。

このリリースには、バグ修正、ドキュメントの更新、および以下の CVE の修正が含まれています。

既に 3.20 を使用しているユーザーにとっては、安全なアップグレードとなるはずです。

Update

Quarkus 3.20 に更新するには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします。

quarkus update --stream=3.20

quarkus update は、Quarkus のあらゆるバージョン (2.x を含む) から Quarkus 3.20 へアプリケーションを更新できることに注意してください。

完全な変更履歴

3.20.6 の完全な変更履歴は GitHub で確認できます。

参加のお誘い

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

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

Apache Polaris は Quarkus を採用しています

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

Apache Polaris は、 Apache Iceberg 用のオープンソースカタログであり、インキュベーション期間を終え、重要な技術的決定として Quarkus をそのクラウドネイティブ基盤として採用することで、正式に Top-Level Project (TLP) へ昇格しました。Iceberg カタログと Supersonic Subatomic Java の融合は、クラウドネイティブな効率性と拡張性だけでなく、コミュニティとの協業も実現し、Polaris をマルチエンジンデータレイクハウスアーキテクチャ向けの主要なソリューションとして位置付けています。

トップレベルプロジェクトへの道のり

Apache Polaris は、Apache Incubator から卒業し、Apache Software Foundation (ASF) 内で新しいトップレベルプロジェクト (TLP) となるという、大きな節目を達成しました。この卒業は、プロジェクトの成熟度とコミュニティへの採用だけでなく、ガバナンスと運用における Apache Way への統合が成功したことを示しています。

Apache Incubator の理解

Apache Incubator は、ASF への参加を目指す「ポッドリング」と呼ばれるプロジェクトのエントリーポイントです。経験豊富なメンターがポッドリングと財団のチーム間の連絡役を務め、実力主義に基づいた合意形成型のガバナンス採用を指導します。Polaris はこのメンター付きのインキュベーションプロセスを無事完了し、コミュニティの成熟度と運用準備の両方を示しました。

インキュベーション期間中の技術的進化

Polaris にとって、インキュベーション期間は単なるガバナンスの練習ではなく、重要な技術開発と戦略的転換を促しました。プロジェクトは、いくつかの重要な変更を実施することで、その適応性と堅牢なアーキテクチャへのコミットメントを示しました。その変更点には以下が含まれます。

新しい JDBC 永続化層：カタログメタデータストレージと設定管理の信頼性と柔軟性を向上させます。
高度なセキュリティ機能：ポリシーベースのカタログアクセスコントロールのための Open Policy Agent (OPA) の実装と、洗練されたオーソライザーフレームワークを通じて、新しいセキュリティ機能を統合します。
堅牢なポリシー管理：マルチテナントカタログデプロイメントの中核機能である、カタログアクセスポリシーと権限を定義および適用するための包括的なフレームワークを開発します。

極めて重要なことに、チームは成功する TLP には将来性のある技術コアが必要であることを認識し、その最も重要なアーキテクチャ上の決定の 1 つである Quarkus の採用につながりました。

Quarkus の採用

これらの技術的進歩の中で、インキュベーションフェーズで行われた最も重要かつ将来を見据えた決定の 1 つは、Apache Polaris を強化するための Quarkus の採用でした。この戦略的な転換は、複数のクエリエンジンに対応する最新の Iceberg カタログには、従来の Java フレームワークが効率的に提供できる以上のものが必要であることを認識していました。チームは、クラウドネイティブデプロイメントの厳しい要件を満たしつつ、迅速なイノベーションに不可欠な開発者の生産性を維持できる技術スタックを必要としていました。

Quarkus は、最新のクラウド環境向けに Java アプリケーションが構築される方法における根本的な変化を象徴しています。複数のクエリエンジンに対応するように設計された Iceberg カタログである Apache Polaris にとって、Quarkus はパフォーマンス、開発者の生産性、およびアーキテクチャの柔軟性の理想的な組み合わせを提供します。

コンテナーファーストアーキテクチャ

Quarkus は、コンテナーファーストの理念に基づいて最初から設計されました。コンテナー向けに後付けで修正された従来のフレームワークとは異なり、Quarkus は、クラスパスのスキャン、設定のロード、依存性注入などの重い計算処理を実行時からビルド時に移行させることで、コンテナー化された環境向けにアプリケーションを特別に最適化します。

Polaris にとって、これは次のことを意味します。

より迅速な水平スケーリング: トラフィックスパイクを処理するために追加のカタログインスタンスをデプロイする場合、コンテナーは秒単位ではなくミリ秒単位で起動します。
高密度化: メモリフットプリントが小さいため、ノードあたりの Polaris インスタンス数が増え、インフラストラクチャコストが削減されます。
効率的なリソース使用: 最小限の CPU とメモリ消費により、運用上のクラウドコストが直接削減され、リソース消費を抑えることで持続可能性のメリットが得られます。

パフォーマンス特性

Quarkus は、次の 4 つの主要な側面を通じてパフォーマンスを提供します。

高速起動時間: アプリケーションの初期化処理をビルド時に実行することで、Quarkus は Polaris を迅速に起動させることができます。これは、Spark、Trino、Flink、またはその他のクエリエンジンからのメタデータ要求のバーストを処理するために、カタログインスタンスが迅速に起動する必要があるオートスケーリングシナリオにとって非常に重要です。数値で示すと、標準的な Quarkus アプリケーションは、ネイティブモードで 10ms、AOT (Leyden) を使用すると約 100ms、プレーンな JVM モードでは 1〜3 秒で起動します。
メモリフットプリントの削減: リアクティブコアは、大規模なスレッドプールを維持するのではなく、少数のイベントループを使用することで、メモリ使用量を劇的に削減し、より高いデプロイ密度を可能にします。
高スループット: Netty と Eclipse Vert.x に基づくリアクティブな非ブロッキングエンジンにより、Polaris は多数の同時カタログ操作を効率的に処理し、メタデータストアやオブジェクトストレージへの I/O 中のブロッキングを最小限に抑えます。この非ブロッキングなリアクティブアーキテクチャにより、Polaris は Spark や Trino からのメタデータリクエストなど、数千の同時クライアント接続を、リクエストごとにスレッドを割り当てることなく処理できるため、スレッド競合のボトルネックを回避できます。
最適化されたリソース消費: ビルド時最適化とリアクティブアーキテクチャの組み合わせにより、CPU 要件が低減され、Polaris を大規模に運用する組織のクラウドコストを直接削減します。

開発者の生産性と汎用性

Quarkus は、豊富なエクステンションエコシステムを備えた、まとまりのあるフルスタックフレームワークを提供し、Polaris コミュニティがインフラストラクチャの配管を構築するのではなく、カタログ機能に集中できるようにします。

摩擦のない開発体験: ライブコーディング機能は、開発中に即座にフィードバックを提供し、内部開発ループを劇的に加速させ、カタログ機能やセキュリティ強化のより迅速なイテレーションを可能にします。

プログラミングモデルの柔軟性: Quarkus は、プレーンな命令型コード、Mutiny API を使用したリアクティブプログラミング、仮想スレッド (JDK 21+) の 3 つの実行アプローチをサポートしており、開発者は各コンポーネントに適切なモデルを選択できます。この汎用性により、Polaris の開発者は、シンプルな管理エンドポイント (ヘルスチェックなど) には慣れ親しんだ命令型パターンを使用しながら、高並行で I/O 集中型のカタログ操作 (メタデータルックアップやコミットなど) にはリアクティブ/非ブロッキングアプローチ (Mutiny または仮想スレッドを使用) を最大限に活用できます。

プロトコルの多様性: REST、gRPC、GraphQL、およびメッセージブローカー (Kafka、RabbitMQ、Pulsar、Apache ActiveMQ) のネイティブサポートにより、Polaris はカタログ API の公開方法や、より広範なデータエコシステムとの統合において柔軟性を持ちます。

Quarkiverse エコシステムの力

コアフレームワークを超えて、Quarkus は、数百ものコミュニティ主導およびベンダーサポートのエクステンションからなるエコシステムである Quarkiverse へのアクセスを提供します。Polaris チームは、カスタム統合を構築するのではなく、永続化 (PostgreSQL、MongoDB)、セキュリティ (OIDC、OPA)、および可観測性 (OpenTelemetry、Micrometer) のために実証済みエクステンションを活用しており、次のセクションでコードベースからの具体的な例とともに説明します。

Polaris が Quarkus をどのように活用するか

Quarkus 基盤の真の力は、Apache Polaris がその実装で特定の Quarkus 機能をどのように活用しているかを調べると明らかになります。カタログサービスは、15 を超える専門エクステンションを統合して、本番対応のクラウドネイティブな Iceberg カタログを提供します。ここでは、統合のいくつかの例を示します。

Quarkus REST を使用したリアクティブなリクエスト処理

Polaris は、Quarkus REST を使用して Iceberg REST API を実装し、Quarkus Reactive Core と SmallRye Mutiny を活用して、何千もの同時メタデータリクエストをスレッドをブロックすることなく非同期で処理します。

Polaris コードベースの実際のレルムコンテキストリゾルバーを以下に示します。

@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));
}

わずか数行のリアクティブコードで、Polaris は、従来のフレームワークでは通常はるかに多くの定型コードを必要とするマルチテナントリクエストルーティングを実現します。

SmallRye Fault Tolerance による回復性

カタログイベントの永続化などの重要な操作には、Polaris は信頼性を確保するために Quarkus Fault Tolerance (SmallRye Fault Tolerance に依存) を使用します。以下に、Polaris がメタデータストアへの回復力のあるフラッシュ操作を実装する方法の例を示します。

@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);
}

この宣言的な回復性アプローチにより、Polaris はメタデータストアへの失敗した書き込みを、設定可能なバックオフとジッターで自動的に再試行し、サンダリングハーダ問題を防止します。設定されたすべての値は、アプリケーション設定で上書きできることに注意してください。

CDI Bean を拡張点として使用する: 永続化層の選択

Polaris は、Quarkus の CDI 修飾子メカニズムを使用して、複数の永続化バックエンド (Quarkus JDBC PostgreSQL エクステンションを介した PostgreSQL、Quarkus MongoDB Client エクステンションを介した MongoDB、およびテスト用のインメモリ) をサポートします。

@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();
}

このアーキテクチャにより、オペレーターは polaris.persistence.nosql.backend 設定プロパティーを変更するだけで、インフラストラクチャ要件に合致する永続化層で Polaris をデプロイできます。

包括的な可観測性

Polaris は、完全な可観測性のために、Prometheus レジストリを備えた Quarkus Micrometer と Quarkus OpenTelemetry を活用します。カタログは自動的に以下を追跡します。

HTTP メトリクス: すべての Iceberg REST API リクエストについて、レルム、操作、ステータスコード別にタグ付けされます。
カタログ固有のメトリクス（テーブル数、ネームスペース数、メタデータ操作のレイテンシーなど）に対応するカスタムゲージとカウンター
最初のメタデータリクエストからストレージアクセスまで、カタログ操作全体でリクエストを追跡する分散トレース

メトリクスエンドポイントは、Kubernetesのベストプラクティスに従い、メインAPIポート (8181) とは分離された、別の管理ポート (8182) で公開されます。

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

QuarkusコミュニティーとPolarisコミュニティーのコラボレーション

Quarkusの採用は、両コミュニティー間で生産的なフィードバックループを生み出しました。両プロジェクトのエンジニアは緊密に協力し、QuarkusがPolaris内で効果的に使用されることを保証し、バグを報告し、途中で可能な改善点を特定しました。この実践的なコラボレーションは、両者に利益をもたらします。Polarisは堅牢で十分に理解された基盤を獲得し、Quarkusは要求の厳しい高スループットのApache TLPデプロイメントから実世界のフィードバックを得て、Quarkusエコシステム全体に利益をもたらす安定性とパフォーマンスの向上を推進します。

将来を見据えて

Apache Polarisがトップレベルプロジェクトとして成功裏に昇格したことと、Quarkusを基盤とすることで得られたパワーと効率は、将来を見据えた重要な技術的課題の出発点に過ぎません。Polarisは、成長のためだけでなく、クラウドネイティブなデータレイクハウスアーキテクチャの未来を積極的に形作る立場にあります。

コミュニティーはすでに、次期メジャーリリースであるQuarkus 4を含む、Quarkusロードマップの最先端に合わせて開発を進めています。この連携により、Polarisはパフォーマンスの向上、新しいクラウドネイティブAPI、およびリアクティブコア向けの最も高度な機能を継続的に利用できるようになります。

私たちのビジョンは、最も重要なデプロイメントの要求を満たすために、新しいネットワーキングおよびセキュリティ標準を採用することにまで及びます。

次世代ネットワーキング: HTTP/3の採用を検討しており、その多重化とヘッドオブラインブロッキングの削減を活用して、メタデータリクエストのレイテンシーをさらに最小限に抑え、スループットを向上させます。これは、数千の同時操作を管理するクエリーエンジンにとって不可欠です。
将来性のあるセキュリティ: 今日の標準を超えて、プロジェクトは量子安全なTLSと暗号化を調査しています。最新の暗号化プラクティスを統合することで、Polarisは現在だけでなく、将来の計算上の課題に対しても安全なカタログを提供することを目指します。

活発なコミュニティーによって推進される継続的なイノベーションへのこのコミットメントは、Apache Polarisが高性能で安全な、マルチエンジンIcebergカタログ相互運用性の業界標準となる準備ができていることを保証します。私たちは、このデータエコシステムの次の時代を定義するために、貢献者、ユーザー、および組織が私たちに参加することを歓迎します。

Quarkus ニュースレター #66 - 3月

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

透明で包括的なパフォーマンス像を提供するため、Quarkusはそのベンチマークを再構築しました。Holly Cumminsによる「Quarkus has great performance – and we have new evidence」で詳細をご覧ください。Guillaume Smetによる「How Project Leyden brought a new perspective」を読んで、Project LeydenがQuarkusにおける起動パフォーマンスについて考える新しい視点をどのように与えたかをご覧ください。Juarez Juniorの投稿「Unleash the Power of AI Agents with Java: Building Intelligent Applications with Quarkus, LangChain4j, and Oracle AI Database」をチェックして、Oracleデータベースのエラーコードに関する顧客サポートを処理するQuarkusベースのAIサポートエージェントを構築する方法を学びましょう。Markus Eiseleによる「Your Java Architecture Is Lying to You: Enforcing Real Boundaries with Quarkus」で、Taikaiを使った実行可能なアーキテクチャテストが、最新のJavaシステムでどのように図、レビュー、部族の知識に取って代わるかをご覧ください。今日、Javaエンタープライズアプリケーションは、フロントエンドにAngular、React、またはVueをデフォルトとすることがよくあります。しかし、この種のアプリケーションには、最も自然なUIフレームワークがJavaエコシステムに既に存在します。それはJakarta Facesです。Nicolas Duminilによる「Rethinking Java Web UIs with Jakarta Faces and Quarkus」で詳細をご覧ください。Markus EiseleがSSE、バッチ処理、PostgreSQLを使ってJava関連の会話を追跡するためのストリーミング取り込みパイプラインをどのように構築したか、「Listening to the Fediverse with Java: A Real-Time Quarkus Experiment」でご覧ください。Hüseyin Akdoğanによる「DPoP: What It Is, How It Works, and Why Bearer Tokens Aren’t Enough」を読んで、DPoP（Demonstration of Proof-of-Possession）とは何か、それが解決する問題、そしてKeycloakとQuarkusを使った動作する実装を見ていきましょう。

また、最新のQuarkus Insightsのエピソード、話題のツイート/ディスカッション、今後開催されるQuarkus参加イベントもご覧いただけます。

ニュースレター #66: 3月をチェックしてください！

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

Quarkus 3.32.3 - メンテナンスリリース

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

本日、Quarkus 3.32.3 をリリースしました。これは 3.32 ストリーム向けの 2 番目のメンテナンスリリースです (3.32.0 はスキップしました)。

3.32 は 3.33 LTS の基盤となるため、LTS リリースを追跡している場合でも、ぜひテストすることをお勧めします。

Update

Quarkus 3.32 にアップデートするには、Quarkus CLI の最新バージョンにアップデートし、以下を実行することをお勧めします:

quarkus update

なお、quarkus update は Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.32 へアプリケーションをアップデートできます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.32 移行ガイドを参照してください。

完全な変更履歴

3.32.3 の完全な変更履歴は GitHub で確認できます。

参加のお誘い

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

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

Quarkus 3.32.2 - メンテナンスリリース

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

本日、Quarkus 3.32.2 をリリースしました。これは、3.32 ストリームにとって最初のメンテナンスリリースです (3.32.0 はスキップしました)。

3.32 は 3.33 LTS の基盤となるため、LTS リリースを追跡している場合でも、ぜひテストしてください。

Update

Quarkus 3.32 に更新するには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします。

quarkus update

quarkus update を使用すると、Quarkus のあらゆるバージョン (2.x を含む) から Quarkus 3.32 へアプリケーションを更新できることに注意してください。

アプリケーションに必要な調整の詳細については、 Quarkus 3.32 移行ガイドを参照してください。

完全な変更履歴

3.32.2 の完全な変更履歴は GitHub で確認できます。

参加のお誘い

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

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

Project Leyden を Quarkus に統合した方法

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

Quarkus は、それぞれ異なるトレードオフに最適化された JVM モードとネイティブイメージモードの両方を長年サポートしてきました。ネイティブイメージは、比類のない起動時間とフットプリントを実現します。JVM モードは、ピークスループット、動的な機能、成熟したツールエコシステムを提供します。

Quarkus はネイティブイメージとの連携を改善し続けており、最近では Project Leyden のおかげで、この方程式の JVM 側を強化することができました。

以前のブログ記事で、Project Leyden と、それが Java アプリケーションの起動パフォーマンスに新たな視点を与えてくれたことへの熱意を共有しました。

この投稿では、Project Leyden を Quarkus に統合するまでの道のり、そしてこの統合をユーザーにとって効率的かつ使いやすいものにするためにどのように取り組んだかを紹介します。

謝辞

まず、Project Leyden に関する取り組みと、Leyden を理解し、Quarkus に統合するための最善の方法を決定する上で非常に役立った多くの議論について、IBM の OpenJDK チームに感謝いたします。具体的には（アルファベット順で）、Maria Arias de Reyna Dominguez 氏、Andrew Dinn 氏、および Ashutosh Mehra 氏です。

より広く、Project Leyden に貢献しているすべての方々に感謝いたします。

Project Leyden はまだ進化途上にあり、Java 27 以降に向けてどのような準備をしているのか楽しみにしています。

最後に、Sanne Grinovero 氏には、適切なタイミングで Leyden チームに紹介していただき、私たちの仕事に対する洞察と貴重なフィードバックをいただいたことに深く感謝いたします。

Project Leyden とは？

GraalVM と Java における AOT の普及

Java の世界では、Java アプリケーションをネイティブ実行可能ファイルにコンパイルする GraalVM ネイティブイメージの登場により、Ahead-of-Time (AOT) コンパイルが注目を集めるようになりました。

これは Java エコシステムに大きな影響を与え、Java アプリケーションの起動パフォーマンスにとって画期的なものでした。

起動時間とメモリフットプリントが大幅に削減されます。
コードはすでにネイティブコードにコンパイルされているため、ウォームアップフェーズはありません。パフォーマンスは実質的に最初からピークに達します。
結果として生成される実行可能ファイルは小さく、より小さなコンテナーイメージにつながります。
Resident Set Size (RSS) メモリ使用量は、通常の JVM アプリケーションと比較してはるかに小さくなります。

しかし、これにはいくつかの欠点があります。

すべての Java 機能とライブラリが OpenJDK と同じようにそのままサポートされているわけではありません。
これはクローズドワールドの仮定に依存し、ほとんどのランタイムダイナミズムを排除します（少なくとも現在の形式では。GraalVM 側の作業によって将来的に変更される可能性はあります）。注記: Quarkus は同じ仮定を置いているため、これは Quarkus にとって問題ではありませんでしたが、サードパーティライブラリにとっては問題となる可能性があります。
特定の制約が導入され、最も一般的なのは明示的なリフレクション設定を提供する必要があることです。これらの要件は開発およびテスト中に労力を追加しますが、Quarkus がサポートするエクステンションの場合、それらは最小限に抑えられます。
ネイティブイメージのビルドは著しく遅くなります。これは通常、内部開発ループに影響を与えませんが（ネイティブ固有の問題をデバッグする場合を除く）、CI リソースに顕著な影響を与える可能性があります。
ネイティブ実行可能ファイルのデバッグは困難です。改善されてはいますが、GDB の使用とビルドにおけるデバッグシンボルの存在が必要であるため、JVM でのデバッグよりもはるかに困難です。
そして、すべてが AOT コンパイルされるため、実行時にコードを最適化する JIT コンパイラが存在せず、場合によっては最適なピークパフォーマンスが得られないことがあります。

全体として、ネイティブイメージは起動時間とフットプリントが主要な目標である場合に優れた選択肢です。

しかし、すべてのアプリケーションがこれらの側面を最適化するわけではありません。一部のアプリケーションは、ピークスループット、開発速度、デバッグ容易性、既存ツールとの互換性を優先します。ここで Leyden が興味深いものになります。これは、従来の JVM モデルに近いままで、起動とフットプリントの改善を目指します。

Project Leyden の AOT へのアプローチ

Project Leyden は GraalVM ネイティブイメージと同じ根本的な問題に対処しますが、異なるアプローチを取っています。

これは依然として「純粋な」Java であり、OpenJDK の一部です。アプリケーションは JVM 上で実行され、特別な設定なしに Java の機能とライブラリに完全にアクセスできます。
トレーニングフェーズ中に、アプリケーションの動作を記録し、ロードされたクラスやリンクされたクラスなどの情報を収集します。より新しいバージョンでは、JIT 出力の一部も記録し始め、各 JVM バージョンでスコープと最適化の可能性を拡大しています。
この情報は AOT キャッシュファイルに保存されます。
起動時に、この AOT キャッシュファイルを使用して JVM を設定します。
アプリケーションは依然として JVM 上で実行されるため、JIT コンパイラ、好みのガーベージコレクタ、およびその他のすべての JVM 最適化の恩恵を受け続け、通常 JVM に関連付けられている高いスループットを維持します。

AOT キャッシュはまさにその通り、キャッシュです。キャッシュにクラスが存在しない場合は、通常通りロードおよびリンクされます。

Project Leyden は、クラスのロードとリンクを最適化することで起動時間を短縮します。JVM にプロファイリング情報を提供することでウォームアップ時間を短縮し、コンパイルされたコード自体がキャッシュに保存されるようになれば、さらに短縮されるでしょう。

Figure 1. Leyden の仕組み

とはいえ、Project Leyden も魔法ではありません。現在の形式では以下のようになります。

起動時間とウォームアップ時間の改善は著しいですが、GraalVM/Mandrel ネイティブイメージほど実質的ではありません。
アプリケーションをトレーニングし、AOT キャッシュを生成する必要があります。実際には、これは難しくなく、Quarkus では可能な限りシームレスにしました。
アプリケーションと一緒に JVM を配布する必要があります。
また、AOT キャッシュも配布する必要があり、これはコンテナーイメージがネイティブ実行可能ファイルよりも大幅に大きくなることを意味します。
現時点ではメモリフットプリントの恩恵は得られません。ほとんどの場合、通常の JVM と同程度です。

私たちの見解では、Project Leyden はパフォーマンスと互換性の魅力的なバランスを非常に合理的なコストで提供し、JVM 上で実行される多くの Java アプリケーションのデフォルトのデプロイメントワークフローの一部となる可能性があります。

Project Leyden のステータス

OpenJDK 25 では、以下の Project Leyden 関連 JEP が利用可能です。

これらの JEP が連携することで、OpenJDK 25 から Project Leyden を完全に利用できるようになります。

追加の JEP は OpenJDK 26 以降で計画されています。

Quarkus における Project Leyden

Quarkus は、広範なビルド時処理と最適化を備えた、非常に特化したフレームワークです。Project Leyden もまた、独自の制約と要件を持つ特化されたテクノロジーです。

私たちの目標は、Quarkus の長所を維持しつつ、Leyden の利点を最大限に引き出す形で Project Leyden を Quarkus に統合することでした。

Quarkus 3.32 には、エンドツーエンドの Leyden 統合の最初のバージョンが含まれています。その仕組みを詳しく見ていきましょう。

AOT JAR パッケージング

お使いの Quarkus アプリケーションが target/quarkus-app/ ディレクトリーにパッケージされているのをご覧になっているかもしれませんが、常にそうだったわけではありません。Quarkus の初期の頃は、他のほとんどの Java フレームワークと同様に、依存関係を lib/ ディレクトリーに配置して、target/ に従来のランナー JAR をビルドしていました。

Quarkus の現在のデフォルトパッケージングは fast-jar と呼ばれています。その主要な目標の 1 つは、クラスローディングを最適化することです。

これを達成するために、独自のクラスローダーを導入しました。このクラスローダーは、たとえば、package name → jar file マッピングをメモリーに保持します。また、META-INF/services のような特定の場所の完全なディレクトリーインデックスを維持するなど、追加の最適化も含まれています。これらはこのパッケージングが行うことのほんの一部ですが、いくつかの文脈を提供できるはずです。

このパッケージングは従来の JVM 環境では非常に優れたパフォーマンスを発揮しますが、Project Leyden とはうまく連携しません。

Project Leyden は保守的なアプローチをとっており、標準の JDK クラスローダーによってロードされたクラスのみをキャッシュします。つまり、AOT キャッシュを最大限に活用したい場合は、カスタムクラスローダーは許可されません。

いずれかの時点で、この制限が Leyden チームによって解除されることを願っています。もしそうなれば、fast-jar パッケージング、またはその進化版に戻る予定です。

正確には、AOT キャッシュを最大限に活用したい場合、クラス をロードするためにカスタムクラスローダーを使用することはできません。ただし、リソース のロードのみを目的としてカスタムクラスローダーを使用することはできます。

これが、Project Leyden 専用のパッケージングである aot-jar を開発した理由です。AOT が有効になっている場合、これは自動的に選択され、移行が完全に透過的になります。これは fast-jar パッケージングと同じファイルレイアウトを使用します。

すべての クラス のローディングを JDK クラスローダーに委譲することに加えて、このパッケージングにはいくつかの特定の特性があります。

META-INF/services からサービスディスクリプターを収集し、それらを統合してメモリーに保持します。
Quarkus 設定ファイル (例: application.properties) にも同じアプローチを適用します。
特定のディレクトリー (例: ルートディレクトリー、META-INF、および META-INF/services) の完全なインデックスを維持します。
事前初期化フェーズを導入し、その間に選択された要素が並行して事前ロードされます (例: タイムゾーンデータベース)。

このパッケージング形式は新しいものであるため、実際の使用状況からフィードバックを収集したいと考えています。

はっきりさせておきますが、Project Leyden が使用されていない場合、aot-jar は fast-jar よりもパフォーマンスが劣ります。

これは fast-jar のすべての最適化を含んでおらず、Project Leyden と組み合わせてのみ使用することを意図しています。したがって、この特定のユースケース以外では使用すべきではありません。

トレーニングと AOT キャッシュの生成

AOT キャッシュは、それを生成するために使用されるトレーニングデータの質に依存します。トレーニングフェーズ中、JVM はロードおよびリンクされたクラスを記録し、メソッドプロファイリングデータを収集します。トレーニングワークロードがより代表的であるほど、結果として得られるキャッシュはより効果的です。

私たちは、Quarkus ユーザーにとってトレーニングが可能な限りシームレスであることを望みました。既存の統合テストインフラストラクチャーを活用するのが自然な選択でした。つまり、すでに @QuarkusIntegrationTest テストがある場合、それらをトレーニングワークロードとして利用できます。

AOT トレーニングが有効な場合、以下のフローになります。

Quarkus は aot-jar パッケージングでアプリケーションをビルドします。
アプリケーションは AOT トレーニングが有効な状態で起動します。
統合テストがアプリケーションに対して実行され、そのエンドポイントと機能を検証します。
JVM はテスト実行全体を通してプロファイリングデータをキャプチャーします。
記録されたデータから最適化された app.aot キャッシュファイルが生成されます。

これは実用的かつ効果的です。あなたはすでにアプリケーションを検証するために統合テストを作成しており、それらはAOTキャッシュ用の比較的現実的なトレーニングデータも生成します。

@QuarkusIntegrationTest を使用する統合テストは、Dev Services を利用するため、ターゲットアプリケーションの実行を非常に簡単にします。

ビルドシステムとの統合

私たちは、Quarkus で Leyden を有効にするのが、1 つのフラグで済む操作であることを望みました。

quarkus.package.jar.aot.enabled=true を設定するだけで十分です。Quarkus は自動的に aot-jar パッケージングに切り替わり、AOT パイプライン全体を設定します。

Maven では、完全なフローは単一のコマンドです。

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

これにより、アプリケーションがビルドされ、AOT トレーニングを伴う統合テストが実行され、target/quarkus-app/ に app.aot キャッシュファイルが生成されます。

私たちのツールで生成されたプロジェクトを使用している場合、統合テストはデフォルトで無効になっています。-DskipITs=false を追加することで、それらが実行されるようになります。

AOT キャッシュを使用してアプリケーションを実行するのも同様に簡単です。

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

また、AOT をコンテナーイメージエクステンション (Jib、Docker、Podman) と統合しました。AOT を有効にしてコンテナーイメージをビルドする際、Quarkus は次の処理を行います。

aot-jar パッケージングでアプリケーションをビルドします。
ベースコンテナーイメージを作成します。
AOT キャッシュをトレーニングするために、コンテナーに対して統合テストを実行します。
AOT キャッシュを含み、起動時にそれを使用するように事前設定された最終的なコンテナーイメージ (バージョンに -aot サフィックスが付加されます) を生成します。

このエンドツーエンドの統合は、単一のコマンドでソースコードから AOT 最適化されたコンテナーイメージへの移行を意味します。

いくつかの数値

Project Leyden の利点は理論上説明しましたが、実際にはどのように機能するのでしょうか？

それを調べるために、2 つの異なる Quarkus アプリケーションについていくつかの数値を収集しました。

quarkus create app を実行したときに得られるシンプルな REST アプリケーション
非常に大規模な REST CRUD アプリケーション: 1,000 エンティティー、1,000 リポジトリー、1,000 サービス、1,000 REST エンドポイント… 合計で 9,000 個の .java ファイル。これは極端なケースなので、自宅では試さないでください！

コンテナーイメージのサイズは、Red Hat の UBI 9 Minimal をベースとし、JDK 25 を使用する当社のデフォルトイメージを使用して測定されました。

生の値

これらの数値は、起動時にロードされたすべてのクラスを完全に記録して取得されました。これらは隔離されたラボ環境ではなく、私たちのラップトップで測定されました。近いうちに、ラボでより包括的なベンチマークセットを実行する予定です。

結果はいくつかの理由で異なる場合があります。

起動時に必要となるすべてのクラスが記録されたわけではありません。
アプリケーションは起動中に実際の作業を実行します。Leyden はクラスのロードのみを最適化し、アプリケーションロジックは最適化しません。

いずれにせよ、予期せぬ結果が見られた場合は、ぜひフィードバックをお寄せください。ご連絡いただければ、有用なプロファイリング情報を収集する方法をご案内します。

RSS は常駐セットサイズ (Resident Set Size) メモリー使用量を指します。

小規模 REST アプリケーション

起動時間差分コンテナーイメージサイズ差分 RSS 差分

	起動時間	差分	コンテナーイメージサイズ	差分	RSS	差分
デフォルト fast-jar	`370 ミリ秒`	`参考`	`456 MB`	`参考`	`122 MB`	`参考`
Project Leyden および aot-jar	`80 ミリ秒`	`-78%`	`495 MB`	`+9%`	`103 MB`	`-16%`
Mandrel ネイティブ実行可能ファイル	`17 ミリ秒`	`-95%`	`155 MB`	`-66%`	`37 MB`	`-70%`

デフォルト fast-jar

370 ミリ秒

参考

456 MB

参考

122 MB

参考

Project Leyden および aot-jar

80 ミリ秒

-78%

495 MB

+9%

103 MB

-16%

Mandrel ネイティブ実行可能ファイル

17 ミリ秒

-95%

155 MB

-66%

37 MB

-70%

AOT キャッシュファイルのサイズは 39 MB で、Quarkus REST アプリケーションで期待できる最小値です。

大規模 REST CRUD アプリケーション

起動時間差分コンテナーイメージサイズ差分 RSS 差分

	起動時間	差分	コンテナーイメージサイズ	差分	RSS	差分
デフォルト fast-jar	`3,189 ミリ秒`	`参考`	`517 MB`	`参考`	`580 MB`	`参考`
Project Leyden および aot-jar	`924 ミリ秒`	`-71%`	`715 MB`	`+38%`	`580 MB`	`0%`
Mandrel ネイティブ実行可能ファイル	`242 ミリ秒`	`-92%`	`244 MB`	`-53%`	`210 MB`	`-64%`

デフォルト fast-jar

3,189 ミリ秒

参考

517 MB

参考

580 MB

参考

Project Leyden および aot-jar

924 ミリ秒

-71%

715 MB

+38%

580 MB

0%

Mandrel ネイティブ実行可能ファイル

242 ミリ秒

-92%

244 MB

-53%

210 MB

-64%

AOT キャッシュファイルのサイズは 198 MB ですが、アプリケーションに 9,000 個の .java ファイルが含まれていることを考えると、驚くにはあたりません。

起動時間

Leyden は、小規模アプリケーションと非常に大規模なアプリケーションの両方で起動時間を大幅に改善します。ネイティブ実行可能ファイルの起動速度には及ばないものの、その結果は依然として素晴らしいものです。

ここで少し立ち止まりましょう。JVM で Quarkus REST アプリケーションをわずか 80 ms で起動できました。

Figure 2. Quarkus は高速に起動します！

確かに、単一のエンドポイントを持つシンプルな REST アプリケーションですが、それでもフル機能の REST 実装に依存しています。そして、JVM で動作します。

非常に大規模なアプリケーションでも、結果は同様に印象的です。起動時間を 71% 削減できました。

コンテナーイメージサイズ

驚くことではありませんが、Container Image に AOT キャッシュファイルを含める必要もあるため、Leyden はイメージサイズを増加させます。

Quarkus REST アプリケーションの場合、最小サイズは約 40 MB です。アプリケーションが大きくなるにつれてキャッシュサイズも大きくなります。

一方、ネイティブ化すると、完全な JVM を含める必要がなくなるため、Container Image サイズが大幅に削減されます。

メモリフットプリント

RSS の観点では、Project Leyden は状況を大きく変えませんが、ネイティブ実行可能ファイルは大幅に低いメモリフットプリントを提供します。

メモリ使用量の削減は、今のところ Project Leyden の主要な目標ではありませんが、将来的に進化する可能性があります。

一歩下がって考えてみましょう

この時点で、「すべてをネイティブにしないのはなぜだろう？」と考えているかもしれません。私たちが概説したすべての理由から、あなたにとって意味のある場合にネイティブを使用してください。

スループットの問題もあります。適切なセットアップがなかったため、私たちはスループットの数値を独自に収集していませんが、一部の同僚が隔離された環境でテストを実行しており、最近新しいベンチマーク結果を公開しました。ネイティブ実行可能ファイルは、少なくとも Mandrel と GraalVM CE で今日オープンソースとして利用できるものについては、通常、スループットが低くなる傾向があります。

ここが Project Leyden が真価を発揮する点です。通常の JVM と比較して起動時間が大幅に高速になりながらも、JVM で実行することのすべての利点を保持します。

Quarkus における Leyden の次なる展開は？

Project Leyden は積極的に進化しており、私たちはその開発を密接に追跡しています。特に OpenJDK Leyden リポジトリの premain ブランチを通じて、実験的な機能が主流の JDK リリースに統合される前に開発されています。

改善が期待されるいくつかの領域があります。

JIT コンパイルされたコードを AOT キャッシュに保存することで、ウォームアップ時間がさらに短縮されます。
カスタムクラスローダーの潜在的なサポートにより、より最適化された fast-jar パッケージングに戻れるようになります。

Quarkus 側では、以下の点にも取り組んでいます。

Windows を含む追加プラットフォームでのテストと検証。

Project Leyden が成熟するにつれて、私たちは新しい機能を Quarkus に統合し続けます。Java 27 以降がもたらすものに期待しています。

まとめ

Project Leyden を Quarkus に統合するための実験と作業を1ヶ月間行った後、私たちはこのテクノロジーの結果と可能性に非常に興奮しています。そして、Quarkus 3.32 に統合できたことを大変嬉しく思っており、皆様はすでにそれを使って試すことができます。

Project Leyden は継続的に改善されており、Java プラットフォームの将来において重要な位置を占める可能性が高いです。最高の開発プラットフォームを提供するという Quarkus の探求の一環として、IBM の OpenJDK チームの協力を得て、私たちはアップストリーム（ git@github.com:openjdk/leyden.git の premain ブランチ）での進捗状況を積極的に監視しており、Quarkus と Leyden のエクスペリエンスをそれに応じて形成し続ける予定です。

AOT サポートにより、Quarkus はそのランタイムの柔軟性を拡張します。プレーンな JVM、Leyden 最適化 JVM、そしてネイティブイメージです。

これらのモードは互いに置き換わるのではなく、トレードオフのスペクトルを形成します。ネイティブイメージは起動と最小フットプリントにおいて比類がありません。Leyden は JVM の起動の利点を強化します。

どれが最適かは、あなたの優先事項、制約、およびアプリケーションのワークロードによって異なります。

私たちのコミットメントは変わっていません。開発者にそのワークロードに最適なオプションを提供し、各パスを改善し続けることです。

参加のお誘い

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

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

Quarkusは素晴らしいパフォーマンスを発揮します。その新たな証拠があります

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

要約

Quarkusにとってパフォーマンスは重要ですが、公開されていたパフォーマンスに関するグラフィックは古く、重要な情報（私たちが素晴らしいスループットを持っているという事実など）が欠けていました。これを解決するために、私たちは透明性があり、再現可能で、パフォーマンスの全体像を測定する新しいベンチマークを作成しました。私たちの実験では、QuarkusはSpring Bootよりも1秒あたり2.7倍多くのトランザクションを処理でき、2.3倍速く起動し、メモリは半分しか消費しません。

物語の始まり

もし quarkus.io サイトを訪れたことがあるなら（もちろん、ここにいるのだから訪れたことはあるでしょう）、フロントページの下部にあるパフォーマンスチャートに気づいたかもしれません。Quarkusチームは私たちのパフォーマンスを誇りに思っています。なぜなら、良いパフォーマンスは高いスケーラビリティ、低レイテンシー、低リソース使用量、低コスト、そしてより良い持続可能性を意味するからです。基本的には、パフォーマンスが重要です。以前に示していたのは次のとおりです。

しかし、パフォーマンスの重要性にもかかわらず、私たちのパフォーマンスチャートにはいくつかの問題がありました。第一に、数字が古いです。どれくらい古いか？それは、チャートに日付がないため、判断が難しいです。実際、その数字がどのように測定されたかについての情報は一切なく、ベンチマークのソースコードへのリンクもありません。これは、誰も再現できないことを意味し、誰も検証できないことを意味します。再現できなければ、信頼できません。

なぜベンチマークのソースコードにリンクしなかったのでしょうか？歴史的に、私たちは比較対象について意図的に曖昧にしてきました（マナーの問題！）。ソースコードを共有すれば、他のフレームワークが何であるかが完全に明らかになっていたでしょう。ベンチマークのソース共有を妨げるだけでなく、他のフレームワークを匿名化することにはそれ自体の問題がありました。フレームワーク名を共有しないことは丁寧ですが、読者に情報に基づいたフレームワークの選択をするための有用な情報を提供しないことになります。Quarkusの方が優れているのか？ああ、はい、間違いなく。何よりも優れているのか？シーッ、それは秘密です。

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

しかし、Quarkusのスループットが悪いという誤解はあちこちで発生しています。外部のブログで何度も出てきますし、お気に入りのAIサービスにQuarkusの利点について尋ねても、スループットに言及する可能性は低いです。その代わりに、起動時間やメモリに焦点を当てるでしょう。それらも重要ですが、スループットも同様に重要です。

私たちのチャートには、Quarkusに関する誤解の一因となっている、もう一つのより微妙な省略があります。私たちはQuarkusのネイティブモードでのパフォーマンスを示していますが、他のフレームワークのネイティブモードでのパフォーマンスは示していません。一部の人々は、これがQuarkusはネイティブモードがすべてであり、Quarkusを使用するならネイティブモードを使用すべきだと解釈します。Quarkusをネイティブモードで、他のフレームワークをJVMモードで比較するブログをよく見かけますが、これは単に愚かです。QuarkusをJVMモードで使う場合は他のフレームワークをJVMモードで使う場合と比較すべきであり、Quarkusをネイティブモードで使う場合は他のフレームワークをネイティブモードで使う場合と比較すべきです。Quarkusはネイティブモードに非常に優れていますが、ネイティブモードを使用するかどうかは、どのフレームワークを選択するかとは直交する選択肢です。

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.

よし、だから私たちは間違いなく新しいベンチマークが必要でした

何かをする必要がありました。幸いなことに、私の同僚であるEric Deandreaは、この正確な問題に数年間取り組んでいました。Ericは、以前John O’Haraが作成したベンチマークに基づいて、制御された条件下でパフォーマンスラボで測定を実行できる一連の自動化を構築していました。

Ericと私は新しいリポジトリを立ち上げ、Ericのベンチマークコードをそこに移動させ、自動化を改良して、結果をラボのファイアウォールを越えてデータストアとして機能する別のリポジトリにプッシュするようにしました。私たちは数値を取得し、( Apache Batik を使用した少しの作業の後) 図も手に入れました！Quarkusのスループットがいかに素晴らしいかに注目してください。Quarkusは、Spring Bootと比較して、1秒あたり2.7倍（19255対7238 tps）多くのトランザクションを処理でき、起動も2.3倍（2.919秒対6.569秒）高速であり、すべて半分のメモリ（583MBではなく269MB）で実現します。

ここからが本当の作業の始まりでした。ベンチマークがオープンソース化されたことで、以前にはなかった方法で厳密な精査にさらされるようになりました。（もちろん、これがオープンソースの魔法の一部です。）Quarkusのパフォーマンス専門家の一人であるFrancesco Nigroは、測定をより堅牢にできるいくつかの領域を発見しました。例えば、私たちのセットアップでは、cgroupsとcpusetを使用してプロセスを特定のCPUコアに固定していました。これは正しいアプローチですが、テスト対象のアプリケーションと負荷ジェネレーターの両方が同じcgroupに集まり、同じコアを奪い合っていました。負荷ジェネレーターが16スレッドを使用するように設定されていたため、これが測定にかなりのノイズをもたらしました。個別のコア割り当てに切り替えることでこれは解決しましたが、データベースが専用のコアを持たないことや、誤ってホスト上のすべてのプロセスに影響を与えていたキャッシュドロップのステップなど、他の干渉源は残っていました。適切な分離が確立されると、スループットの結果は微妙に変化しました。修正前は、負荷が低いことで他のプロセスにより多くの余裕が生まれていたため、遅いフレームワークも競争力があるように見えました。彼らは、自分たちが引き起こす競合が少ないという点で過大評価されていたのです。上記のチャートは、改善されたセットアップを反映しています。これこそが、ベンチマークにはスキルが必要だと私が先に言ったことです。これらの間違いは簡単に起こり、検出が微妙なのです。

しかし、最も大きな助けはQuarkusコミュニティの外から来ました。ベンチマークの意図は、通常のユーザーの体験を再現することであり、各フレームワークを極限までチューニングすることではありませんでした。（そのためには TechEmpower があります。）「初期設定（out of the box）」のパフォーマンスを測定することが最善の道だと考えました。その理由の一つは、ほとんどの人がデフォルトで経験するパフォーマンスだからであり、もう一つはそれが最も公平だったからです。公平性は重要な目標でした。そうでなければ、比較する意味がありません。私たちのチームはQuarkusアプリケーションを非常に鋭いパフォーマンスにチューニングするスキルを持っていますが、私たちのほとんどはSpringに対して同じスキルを持っていません。それは私たちの職務記述書にはないのです。QuarkusだけをチューニングしてSpringをチューニングしないのは明らかに公平 ではない でしょう。

しかし、最初の結果を公開し始めてから、Spring Boot を日常的に使用している人々から連絡がありました。彼らは、両フレームワークが open-session-in-view 設定と接続プールサイズの処理において違いがあると指摘しました。これらの違いは十分に大きく、初期設定の動作を比較することが、実際に 最も公平な選択肢であったか どうかを評価し始めました。open-session-in-view 設定と N+1 問題の修正は数値に大きな違いをもたらしませんでしたが、接続プールサイズの調整は違いをもたらしました。デフォルト設定では、Spring アプリケーションは深刻な接続エラーに悩まされていました。クライアントが接続できない場合、スループットはゼロになるため、エラーがスループットを低下させていました。Eric、Francesco、Sanne Grinovero は、Spring アプリケーションがエラーなしで負荷を処理できるように、ログを詳細に調査し、プロファイリングを行って設定の微調整を見つけ出すために多くの時間を費やしました。

私たちのSpringの友人たちは、このような調整は完全に標準的なものだと教えてくれました。私たちは依然として初期設定のパフォーマンスを測定したいと考えていたため、妥協案に落ち着きました。初期設定バージョンと、軽くチューニングされたバージョンの両方を測定しました。フロントページに表示しているグラフィックでは、チューニングされたバージョンを表示しています。以下に、同じコードレベルとスクリプトを使用した、上記の初期設定の結果に相当するチューニング版を示します。

チューニングの効果は、全体的にかなり控えめだったことがわかります。また、スループットとメモリフットプリントの間には多少のトレードオフがあったことにも注目してください。どちらのフレームワークでも、チューニングによる最適化は、速度向上のために一部のメモリを犠牲にすることになりました。

基本原則

チューニングの問題をどのように扱うかを決めようとする中で、私たちはこの取り組み全体の基本原則に立ち返ることになりました。それらは次のとおりです。

同等性

Spring版とQuarkus版のアプリケーションのコードは、同じ機能を実行するために可能な限り同等であるべきです。これは、ドメインモデルが同一であり、基盤となる永続化メカニズムが同一であるべきであることを意味します（私たちのケースでは、Hibernateを使用するJPA）。パフォーマンスの違いは、フレームワーク自体のアーキテクチャの違いとライブラリ統合の最適化から生じるべきです。アプリケーションのアーキテクチャを変更する変更（つまり、ブロッキングをリアクティブに移行する、仮想スレッドを使用するなど）が行われる場合、これらの変更はアプリケーションのすべてのバージョンに適用されるべきです。

標準性

パフォーマンスの最後のひとひねりまで絞り出すことよりも、現実性が重要です。

高い品質

アプリケーションはベストプラクティスをモデル化する必要があります。アプリケーションが典型的な使い方を表すことを望んでいますが、それをコピーする人が「間違った」または悪いコードをコピーするべきではありません。

インフラではなくフレームワークのテスト

測定は、データベースのようなサポートインフラストラクチャではなく、フレームワークのパフォーマンスを測定するものであるべきです。実際には、これは実験セットアップがCPUバウンドであることを意味します。

パフォーマンスの探求

この作業の素晴らしい点の一つは、「Quarkusには素晴らしいパフォーマンスがあるのか？」という問いを超えて、パフォーマンスに関する様々な疑問を探求できるようになったことです。例えば、仮想スレッドで実行すると結果に影響があるでしょうか？はい！すべてのフレームワークで、仮想スレッドは約6,000トランザクション/秒を追加しました。

そして、他にも疑問がありました。Spring Boot 3とSpring Boot 4の間でパフォーマンスに違いはあったのでしょうか？いくつかの点で改善され、いくつかの点で悪化したことが判明しました。Spring 4はSpring 3よりも高いスループットを提供しますが、最初の応答までの時間が遅くなり、メモリフットプリントも増加するという犠牲を伴います。

Quarkusの新しい AOTパッケージングは起動時間にどのような影響を与えるでしょうか？（これについてはまだ作業中ですが、その答えを見るのが楽しみです。）

スループットと起動時間のトレードオフ、再訪

Quarkusでは、起動時間とパフォーマンスの間にトレードオフがないと述べました。他のフレームワークと比較した場合、これは確かに真実です。ビルド時の原則のようなQuarkusの内部効率は、起動時間とスループットの両方を改善します。しかし、JVM上のQuarkusをネイティブのQuarkusと比較すると、トレードオフが再び現れます！GraalVMを使用してQuarkusアプリケーションをネイティブにコンパイルすると、Quarkusは電球よりも速く起動し、非常に小さなメモリフットプリントを持っています。しかし、スループットのペナルティ はあります 。ネイティブにするとスループットは半分になります。（Spring Bootの場合、ネイティブのペナルティは同様です。）ほとんどのアプリケーションにとって、このトレードオフは価値がありません。特に、より長いビルド時間やネイティブの追加の制約と組み合わせるとそうです。しかし、時にはトレードオフに価値がある場合もあります。アプリケーションが非常に頻繁に起動および停止される場合や、非常に低いワークロードの場合は、ネイティブを使用してください。

自宅でベンチマークを試してみたいですか？

可能です！すべてのソースコードとスクリプトは https://github.com/quarkusio/spring-quarkus-perf-comparison で利用できます。誰もが簡単に再現できることは、ベンチマークを設計する上で重要な基本原則でしたが、少々複雑になります。パフォーマンスの世界では、「厳密」と「簡単」は同じ文脈では使用されません。難しいことを常にアクセスしやすくしたい私としては、これは 本当に 歯がゆいです。結局、私たちは妥協点に落ち着きました。もし手元にパフォーマンスラボがあるなら、もちろん理想的です。すべてのスクリプトが自分のハードウェアでジョブを実行できるように利用可能です。そのようなセットアップがなくても、Linuxマシンがある場合は、私たちが使用する専門家が承認したスクリプトを使用できます。内部的には、それらはオーケストレーションに qDup のようなツールを使用し、協調的な省略のリスクなしに負荷を駆動し、プロセスの分離を確実にするために Hyperfoil を使用しています。

しかし、 本当に 簡単なものが欲しい場合はどうでしょう？この時点から、物事は難しくなります。私たちは、シンプルさを追求したスクリプトの第2バージョンを作成しました。これらは馴染みのあるツールのみを使用し、プロセス分離は試みません。そのため、MacとLinuxの両方、そして適切なターミナルがあればWindowsでも実行できます。ただし、結果は注意して扱う必要があります。ラップトップの電源管理はあらゆる種類の奇妙な影響を引き起こす可能性があり、負荷が多すぎたり少なすぎたりすると、QuarkusやSpringとは関係のないボトルネックを測定してしまう可能性があります。最も一般的な問題を回避する方法や、測定しているものが自分が考えているものかどうかを判断する方法について、別のブログ（または6つ！）を計画しています。

Quarkus 3.32 - Project Leyden の統合、より優雅なシャットダウン、自動 Consul 登録など！

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

Quarkus 3.32 のリリースをお知らせいたします。

これは重要なマイルストーンです。3.32 は、次期 LTS リリースである Quarkus 3.33 LTS の機能凍結を示します。今後の LTS は 3.32 ラインから分岐され、このリリースが 3.33 LTS が構築される基盤となります。

Quarkus 3.32 は、いくつかの重要な改善点と新機能も提供します。

#52376 および #52224 - Project Leyden の統合
#50975 - HTTP に関してより優雅になるよう、優雅なシャットダウンを再構築
#47997 - Quarkus アプリケーションの自動 Consul 登録
#52090 - OIDC: カスタム DPoP ノンスプロバイダーのサポート
#52353 - OIDC: リッチ認可リクエストの基本的なサポートを追加
#52175 - 組み込みの認証メカニズムの順序をカスタマイズ可能にする
#52537 - OIDC AuthenticationCompletionAction の導入
#52380 - Google Cloud Function フレームワーク 2.0 へのアップグレード

早急に 3.32 にアップグレードすることを強くお勧めします。これにより、フィードバックを収集し、今後の 3.33 LTS が可能な限り安定していることを確認できます。

現在 3.27 LTS を実行している場合は、今が 3.33 LTS へのアップグレードパスを検証するのに最適な時期です。問題が発生した場合はお知らせください。この段階でのフィードバックは特に貴重です。

Update

Quarkus 3.32 に更新するには、Quarkus CLI の最新バージョンに更新し、以下を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.32 へアプリケーションを更新できます。

アプリケーションに必要な調整に関する詳細は、 Quarkus 3.32 移行ガイドを参照してください。

変更点

Project Leyden の統合

Project Leyden は、Ahead-of-Time (AOT) コンパイルを JVM にもたらします。トレーニング実行中にクラスロード、クラスリンク、およびメソッドプロファイリングを記録することで、JVM が後続の実行に使用できる AOT キャッシュファイルを生成できます。

その結果、制約や欠点がほとんどなく、JVM の起動時間が大幅に改善されます。

Project Leyden は OpenJDK 25 (LTS リリースのみをカウント) から利用可能です。近日中に専用のブログ記事で詳細を説明します。

Quarkus では、Project Leyden AOT を統合しました。これにより、

トレーニング実行は、ビルド時 (最小限のトレーニング) にトリガーすることも、統合テストを通じてトリガーすることもできます。
生成された AOT キャッシュファイルは、コンテナーイメージに直接含めることができます。

改善はネイティブ実行可能ファイルほど実質的ではなく、AOT キャッシュファイルのためにコンテナーイメージサイズが若干大きくなりますが、必要とされる労力が最小限であることを考えると、その結果は印象的です。

quarkus create app で作成された最小限の REST アプリケーションは、起動時間が370 ミリ秒から80 ミリ秒に短縮されました。
9,000 クラスを持つ大規模な REST CRUD アプリケーションは、3 秒から 900 ミリ秒になります。

詳細については、 Quarkus AOT ガイドを参照してください。近日公開のブログ記事で、詳細なチュートリアルを共有します。

優雅なシャットダウン

Keycloak チームの作業により、HTTP の優雅なシャットダウンにいくつかの改善が加えられました。

Stork

Quarkus アプリケーションは、Stork エクステンションを使用して Consul に自動的に登録できるようになりました。

この新機能は、 Quarkus 用 SmallRye Stork による自動サービス登録ガイドで詳しく説明されています。

セキュリティー

いつものように、このバージョンには新しいセキュリティ機能と機能強化が含まれています。

#52090 - OIDC: カスタム DPoP ノンスプロバイダーのサポート
#52353 - OIDC: リッチ認可リクエストの基本的なサポートを追加
#52175 - 組み込みの認証メカニズムの順序をカスタマイズ可能にする
#52537 - OIDC AuthenticationCompletionAction の導入

Google Cloud Function

Google Cloud Function フレームワークが 2.0 に更新されました。

プラットフォームの更新

Camel Quarkus を Camel Quarkus 3.32 に更新しました。詳細については、発表を参照してください。

Quarkus CXF も 3.32 に更新されました。以前の Quarkus の発表に 3.31.1 のリリースノートを含めるのを忘れていたため、両方のリリースノートを読むことができます: 3.31.1および 3.32.0。

完全な変更履歴

3.32.0.CR1、 3.32.0、および 3.32.1 の完全な変更履歴は GitHub で確認できます。

コントリビューター

Quarkus コミュニティは成長しており、現在 1163 名の貢献者がいます。皆様に心より感謝申し上げます。

特に 3.32 リリースに関しては、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、および Yoann Rodière に感謝いたします。

参加のお誘い

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

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

Project Leyden がもたらした新しい視点

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

これは Project Leyden にまつわる物語です。そして、これは Project Leyden だけの物語ではありません。

これは、Project Leyden が Quarkus、そしてより広くは Java 全体における起動パフォーマンスの考え方に、いかに新しい視点を与えてくれたかという物語です。

これは、フレームグラフが登場する物語でもあります。

これこそ、最高の物語だと思いませんか？

謝辞

私はこの道のりを、親愛なる同僚である Georgios Andrianakis と共に歩みました。彼はこのプロジェクトを実現する上で極めて重要な役割を果たしました。これこそまさに、誰かと共有したくなるような素晴らしい道のりでした。

物語の始まり

すべては、Quarkus の起動パフォーマンスを改善するのが非常に難しくなってきたと、私が何度もぼやいたことから始まりました。起動プロセスはクラスロードのノイズで埋め尽くされていました。つまり、起動時のプロファイルを確認するたびに、何か怪しい部分をクリックしては次のように気づくことの繰り返しだったのです。

「ああ、これはただ初めてクラスをロードしているだけか… がっかりだ」

私は忍耐強い人間です。しかし、1 日にマウスをクリックできる回数には限りがあります。

そんなある日、シャワーを浴びているときに、あるアイデアが浮かびました。

「Project Leyden は、他の機能とともにクラスロードの問題も改善してくれるはずではないか？」

Project Leyden を使ってクラスロードのノイズを取り除けば、起動中に実際に何が起きているのかをより明確に把握できるのではないかと考えたのです。

結局のところ、これはかなり奥の深い話になりました。Project Leyden は期待を大きく上回る結果をもたらし、最終的に Georgios と協力して Quarkus に密接に統合することになりました (別のブログ投稿が続くことが予想できますよね？)。

しかし今日は、皆さんが楽しみにしているフレームグラフをお約束しました。さあ、本題に入りましょう！

視点の転換

これについては今後のブログ投稿で詳しく説明しますが、現時点では、Project Leyden がクラスをロードおよびリンクされた状態でキャッシュし、メソッドのプロファイリング情報や、将来的にはコンパイル済みコードなどの追加メタデータも保持できることを知っておけば十分です。

実際には、Project Leyden はクラスのロードやリンクといったコストのかかる作業を専用のトレーニングフェーズに移行させることで、Java の起動パフォーマンスを向上させます。この状態を事前にキャプチャしておくことで、アプリケーションは通常実行時に行われる冗長なセットアップの多くをスキップできます。

言い換えれば、すべてが適切に記録されていれば、クラスロードを起動パスからほぼ完全に排除できるのです。

すると突然、未知の領域に足を踏み入れることになります。シンプルな quarkus create app で作成した Quarkus REST アプリケーションが 130 ミリ秒で起動するのです。

これだけでも十分に素晴らしいですよね？しかし、さらに興味深いのは、私たちがそれ以上の成果を上げることができた点です (次のブログ投稿でお会いしましょう、覚えていますよね？)。

ここで視点が大きく変わります。約 100 ミリ秒で起動する場合、節約する十数ミリ秒のすべてが意味のある改善になります。もはや 5 ミリ秒のコストを無視することはできません。

誰かが叫んでいるのが聞こえます。

「言葉はいいから！フレームグラフを見せてくれ！」

わかりました、わかりました。

エコシステム全体としてどのように改善できるか

始める前に、非常に重要な注意点があります。 ここで特定のライブラリーやフレームワークを批判するつもりはありません。Quarkus 自体にも簡単に改善できる点が見つかりました。 私たちは皆、同じ船に乗っているのです。

このブログ投稿の目的は、Project Leyden が、あまりにも長い間隠されていたものを明らかにするのにいかに役立ったかを示すことです。そして、これが他のライブラリーやフレームワークの作者にいくつかの有益なアイデアを提供し、最終的に Java エコシステム全体の改善につながることを願っています。

最悪の場合でも、少なくともフレームグラフは見られますからね \o/。

互換性レイヤー

Figure 1. 仮想スレッドが利用可能か判断しようとする Netty

多くのライブラリーには、複数の JDK バージョンをサポートするための互換性レイヤーが含まれています。通常、これらは仮想スレッドなどの機能が利用可能かどうかを判断するためにリフレクションに依存しています。

Quarkus エコシステムでは、Netty や Vert.x などの低レベルライブラリーでこれが一般的です。しかし実際には、このパターンはいたるところで見られます。

これを避けるべきです。これにはコストがかかり、そのコストはこれらのライブラリーを使用するすべてのアプリケーションの 起動のたびに 支払われます。

マルチリリース JAR も完璧ではありません。メンテナンスが難しく、テストも難しく、IDE で常に十分にサポートされているわけでもありません。しかし、この問題は解決してくれます。そして、ライブラリーやフレームワークの作者として、コストをアプリケーションの起動時ではなく、ビルド時に一度だけ支払うようにするのは私たちの責任であると私は主張します。

Georgios とともに、アプリケーションが特定の機能をサポートする Java バージョンをターゲットにしている場合に、これらのライブラリーの一部のバイトコードをビルド時に書き換え、リフレクション呼び出しを削除して直接呼び出しに置き換える実験を行うことにしました。

これは少しハック的であり、長期的にメンテナンスしたいものではありませんが、アイデアを検証し、迅速に成果を上げるための素晴らしい方法でした。

アノテーションの読み込み

これは私たちにとって新しいことではありません。そもそも Quarkus を作成した理由の 1 つは、実行時のアノテーションの読み込みを避けることでした。

ほとんどのユースケースでは、ビルド時にアノテーションを処理し、必要なバイトコードを生成できるため、実行時に検査する必要はありません。私たちのアノテーションインデクサーである Jandex は、このための素晴らしいツールであり、Quarkus で広く使用されています。しかし… Quarkus でさえ、実行時にアノテーションが読み込まれるケースがまだ存在します。

なぜアノテーションの読み込みはこれほどコストがかかるのでしょうか？それは、アノテーションの解析にコストがかかるからです。これは実行時に初めてアクセスを試みたときに発生し、JDK はアノテーションの値を公開するためのプロキシインスタンスを作成します。

Netty とマーカーアノテーション

Figure 2. ChannelHandler が共有可能かどうかを判断しようとする Netty

Netty のケースは、インターフェースの実装の機能を判断するためにアノテーションを読み込んでいるため、特に興味深いものです。

このようなユースケースには、アノテーションの代わりにマーカーインターフェースまたはメソッドを使用することをお勧めします。

Georgios は再びバイトコードの書き換えを利用して、アノテーションのルックアップを排除しました。これもまた、長期的にメンテナンスしたいものではありません。

Hibernate ORM

Hibernate ORM もこの文脈において非常に興味深いものです。

最初の重要な点は、Quarkus における Hibernate ORM では、依然として実行時にメタデータを構築しているということです。つまり、実行時に多くのアノテーションを読み込むことになります。この状況を改善するための長期的な取り組みはすでに始まっていますが、これは大規模なプロジェクトであり、メタデータの構築をビルド時に移行できるようになるまでには時間がかかります。

それはひとまず置いておきましょう。

また興味深いのは、Hibernate ORM が実行時に、Hibernate 独自のアノテーションと JPA アノテーションの両方について、自身のメタデータを収集している点です。これは膨大な量のアノテーションであり、処理すべきメタデータも大量にあります。

Figure 3. 自身のアノテーションに関するメタデータを収集する Hibernate ORM

たとえば、JPA または Hibernate の各アノテーションに対して、アノテーションのターゲット (クラス、メソッド、フィールド) や、それが継承されているかどうかを判断します。

結局のところ、めったに変更されないものに対して、かなりの量のアノテーション処理が行われていることになります。

私は少し前にこの問題を特定し、Hibernate チームの同僚である Luca Molteni が近いうちに調査する予定です。修正がどれほど容易かはまだわかりませんが、要旨は理解していただけるでしょう。可能な限り、この種のメタデータは一度だけで完全に解決されるべきです。そして、テストによってその正確さを強制し、正確で最新の状態を維持できるようにすべきです。

近いうちにこれを改善できることを願っています。そして、ここでの改善は Quarkus アプリケーションだけでなく、Hibernate ORM を使用するすべてのアプリケーションに利益をもたらすという点が素晴らしいところです。

ロードにかかる新たなコスト

Leyden を使用しない場合、膨大な数のクラスをロードすることになります。 JAR ファイルはどうせ開かれるので、それは "fine" とされます。まあ、何をもって "fine" とするかによりますが。

Leyden を使用すると、起動時にクラスがまったくロードされないというレベルにまで到達できます。

つまり、クラスパスから何かをロードしようとする試みはすべて、JAR ファイルを開き (最初にアクセスされたとき)、ディスクから読み取る動作をトリガーすることになります。

そして、いくつかのリソースがクラスパスからロードされることは間違いありません。

JDK や多くのライブラリー、フレームワークがインターフェースの実装を見つけるために使用する ServiceLoader のサービスファイル (META-INF/services/ 内のもの)。
設定ファイル。
そして、おそらく他にも多くのものがあります。

存在しないクラスとリソース

なぜ存在しないクラスをロードしようとするのでしょうか？それは良い質問です。

Figure 4. 存在しない package-info をロードしようとする Hibernate ORM

package-info.java ファイルを覚えていますか？たとえば Hibernate ORM は、パッケージレベルのアノテーションを検査するためにこれらをロードしようとします。多くの場合、これらのファイルは存在しませんが、それは完全に正常なことです。

クラスロードのキャッシュは Leyden のスコープ内ですが、Leyden はネガティブキャッシュ (存在しないことのキャッシュ) は行いません。なぜでしょうか？Leyden は AOT (事前コンパイル) ですが、依然として真の Java だからです。Java は動的な言語です。キャッシュを記録したときにクラスが存在しなかったとしても、後で追加されるかもしれません。実際には、特に「閉じた世界 (closed world)」を前提とする Quarkus ではそうではないことが多いのですが、Leyden はその前提に頼ることはできません。

Quarkus で Leyden を使用する場合、エンティティを含むすべてのパッケージに対して、まだ存在しない場合に空の package-info クラスを生成することにしました。これにより、Hibernate ORM は存在しないクラスをロードしようとする必要がなくなります。

Figure 5. 存在しないクラスをロードする JBoss Logging

別の例は JBoss Logging の国際化です。現在のロケールのクラスをロードしようとし、そのクラスが存在しない場合はデフォルトのクラスにフォールバックします。

リソースでも同様のパターンが見られます。アプリケーションが存在しない設定ファイルやサービス記述子をロードしようとすることがあります。それは完全に正常であり、欠落していることを知る唯一の方法は試してみることです。

Quarkus では、これを軽減するためのクラスローダーのトリックをいくつか持っています。しかし、一般的なケースでは、それに対処する必要があります。

ここに落とし穴があります。これらすべてのケースで、ランタイムはクラスパス全体を走査し (何も見つからないことを思い出してください)、クラスやリソースを特定しようとします。その際、クラスやリソースが存在しないという結論を出すためだけに、大量の JAR ファイルを開いて読み取る可能性があります。

確かに JAR 全体を読み取るわけではなく、各アーカイブにはインデックスがありますが、それでもコストはかかります。

ServiceLoader

Figure 6. ServiceLoader の嵐

ServiceLoader のケースを詳しく見てみましょう。これは特に興味深いものです。

クラスロードが問題にならなくなると、起動時間のかなりの部分が JAR ファイルからのサービス記述子のロードに費やされていることが明らかになります。私たちはクラスローダーのトリックを使って一部のサービスでこれを改善できましたが、それはスレッドコンテキストクラスローダーを通じてロードされるサービスに対してのみ有効です。JDK クラスローダーによってロードされるサービスについては、まだ良い解決策がありません。少なくとも今のところは。

次回のブログ投稿では、Project Leyden 自体と、それをどのように Quarkus に統合したかについて詳しく説明します。お楽しみに。

その他の面白い事実

UUID の生成

Figure 7. 初めて UUID を生成する動作

これは単純明快です。 UUID を生成するたびに、JDK は SecureRandom インスタンスを初期化します。そして、 SecureRandom インスタンスの初期化は、決してタダではありません。

もちろん、アプリケーションがいずれにせよ SecureRandom を必要とするのであれば気にすることはありません。しかし、必要ない場合に、お気に入りのフレームワークが内部用途のために UUID を生成するのは理想的ではありません。

言うまでもなく、アプリケーションが本当に UUID 生成を必要とするのであれば、そのまま使用してください。

BigDecimal

Figure 8. BigDecimal の初期化

同様に、 BigDecimal クラスには、実際にはかなりの量の作業を行う静的初期化子があります。 BigDecimal の初期化には、無視できない時間がかかることがあります。

私たちがこれに遭遇したのは、Quarkus の起動時間を出力する際にいくつかの計算を行うために BigDecimal を使用していたからです。

なんてことだ。

そのコードを置き換えましたが、別の問題が見つかりました。 Hibernate ORM の DurationJavaType クラス内の非常に限定的なユースケースでも、 BigDecimal が先行して初期化されていました。これもすでに修正されています。

UUID と同様に、アプリケーションが本当に BigDecimal を必要とするのであれば、それを使用してコストを支払うべきです。

これは、実際には必要のないときのコストを避けるための話です。

タイムゾーン

Figure 9. タイムゾーンデータベースのロード

タイムゾーンの扱いが難しいことは誰もが知っています。しかし今、私たちはそのロードも遅いということを知りました。

タイムゾーンデータベースはかなり大きく、たとえば TimeZone.getDefault() を呼び出す際などにそれをロードすると、目に見えるほどの時間がかかることがあります。

サーバーアプリケーションでタイムゾーンを必要とする人なんているでしょうか？たとえば、ローカルのタイムゾーンでタイムスタンプを出力したいロギングレイヤーなどがそうです。

Figure 10. ゾーンルールのロード

さらに興味深いのは、タイムゾーンを ZoneId に変換する際にも、ゾーンルールをロードする必要があるため、追加のコストがかかることです。

これら 2 つの問題は依然として存在しており、解決できるかどうかもわかりませんが、AOT 用に開発した特定のパッケージングを使用することで、Quarkus ではそのコストをある程度軽減することができました。

結論

この投稿は、Quarkus と Quarkus が依存するライブラリーで行った作業についてです。しかし、私たちが学んだ教訓は Java エコシステム全体に適用できるものだと私は考えています。

私たちの経験を共有することで、他のプロジェクト、特にライブラリーやフレームワークの作者が同様のアプローチをとり、起動パフォーマンスを向上させるきっかけになれば幸いです。

正直なところ、これは単に起動パフォーマンスを向上させるだけでなく、起動時に浪費されるリソースを削減することでもあります。私たちはよく Green IT について話しますが、特に簡単に達成できるケースでは、ライブラリーやフレームワークをよりグリーンなものにしていきましょう。

私たちの発見やレシピのいくつかを共有しましたが、各ライブラリーやフレームワークに固有のものは他にもあるはずです。今こそ自分たちの起動プロファイルを確認し、パフォーマンスを向上させるための「低いところにある果実 (簡単に改善できる点)」を見つける絶好の機会です。Quarkus 3.32 と新しい AOT 統合がまもなく登場すれば、これはかつてないほど容易になるでしょう。

質問がある場合は、こちらのコミュニティーでお待ちしています。また、何か面白いものを見つけたら、ぜひ共有してください。お話を聞けるのを楽しみにしています！

さらなる高みへ！

コミュニティーへの参加

私たちは皆様からのフィードバックを大切にしています。バグ報告や改善要望など、ぜひお寄せください。一緒に素晴らしいものを作り上げましょう！

Quarkus ユーザーの方も、興味があるだけの方も、遠慮なく私たちの温かいコミュニティーに参加してください。

GitHub でフィードバックを送る。
コードを書いて PR を送る。
Zulip やメーリングリストで議論する。
Stack Overflow で質問する。

Quarkus Chicory を活用した Java による Go CEL ポリシーエンジンの構築

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

数日前、我々は Quarkus Chicory の最初のバージョンをリリースしました。これは、 Chicory WebAssembly ランタイムのパワーを Quarkus アプリケーションにもたらすエクステンションです。

開発を繰り返す中で、実際のユースケースに基づいた統合テストを実装する必要性を感じました。

一般的なシナリオについての調査と実験を重ねた結果、最終的に非常に興味深いものにたどり着きました。

Kubernetes スタイルの CEL ポリシーエンジン

CEL を使用すると、Kubernetes リソースの式ベースのポリシー検証が可能になります。この要件はオペレーターによって実装されますが、それらは通常 Go で記述されています :-)

しかし、Keycloak オペレーターのように Java ベースの Quarkus オペレーターも存在します。ではどうすればよいでしょうか。Java で CEL ポリシー検証エンジンを一から実装しなければならないのでしょうか。それとも、 https://github.com/projectnessie/cel-java などの適切な Java ライブラリーを探すべきでしょうか。

そのどちらでもありません。ここで、Java 用の WebAssembly ランタイムである Chicory が役に立ちます。

広く使用され、十分にテストされた Go ライブラリーを再利用しましょう。Java からエクスポートされた関数をサンドボックス化された安全な方法で呼び出すだけで、すべてが解決します。

なぜか？

書き直しの必要がない
メンテナンスコストが低い
1:1 の動作再現

Quarkus アプリケーション用 Chicory エクステンション

Chicory は、オープンソースの 100% ネイティブ Java WebAssembly (Wasm) ランタイムです。

その主な目的は、Java 開発者がネイティブライブラリー、JNI (Java Native Interface) の使用、または unsafe なコードに依存することなく、JVM 内で Wasm モジュールを実行できるようにすることです。

プラットフォーム固有のバイナリーを必要とする他の Wasm ランタイムとは異なり、Chicory はピュア Java です。

JVM のメモリー空間内で Wasm コードを実行し、「ダブルサンドボックス」効果 (Wasm の分離 + JVM のセキュリティー) を提供します。また、Wasm モジュールがシステムリソースと安全にやり取りできるようにする WASI (WebAssembly System Interface) サポートも提供します。さらに、高速な実行のための インタープリター と ランタイムコンパイラー の両方に加え、Wasm を Java バイトコードに変換して最適なパフォーマンスを実現する ビルド時コンパイラー も含まれています。詳細は Chicory execution modes を参照してください。

これはプラグインシステムに理想的であり、ユーザーが Wasm にコンパイルされる任意の言語 (Rust、C++、Go など) で安全なプラグインを記述し、それを Java アプリ内で実行できるようにします。また、Java ベースのインフラストラクチャー上でアプリケーションコンテナーのオーバーヘッドなしに軽量なロジックを実行する手段を提供するため、サーバーレスやエッジコンピューティングのケースにも使用できます。

そして、古びることのないクロスプラットフォームのポータビリティーについても、アーキテクチャーごとに異なる .so や .dll ファイルを管理することなく、アプリケーションは "Write Once, Run Anywhere" 状態を維持できます。

Chicory についての詳細を確認できますが、ここからはその Quarkus エクステンションに焦点を当てましょう。

Quarkus Chicory は、Chicory を Quarkus アプリケーション開発者にもたらし、その機能を Quarkus エコシステムやアプリケーションのビルド時および実行時の特性に統合して、自然な開発体験を提供します。まさに、ただ動くのです！

主な機能

ビルド時のコード生成

WebAssembly モジュールから Java バイトコードを生成し、Chicory Maven プラグインを置き換えます。

依存関係管理

Quarkus と Chicory の ASM 依存関係間のバージョン整合性を自動的に処理します。

マルチ WASM モジュールサポート

複数の WebAssembly モジュールを構成および管理します。

動的ロード

実行時にロードされる WASM モジュールを管理します。

実行モードのインテリジェントな選択

環境に基づいて MachineFactory と WasmModule インスタンスを構成します。 MachineFactory は、本番環境やネイティブ環境で最適なパフォーマンスを得るためにビルド時に生成されたバイトコードを活用し、開発やテストの際にはランタイムモードやインタープリターモードを使用できます。同様に、 WasmModule インスタンスも、ビルド時のコード生成プロセスを活用することで、純粋な WASM ペイロードではなく WASM メタデータを使用して初期化でき、パフォーマンスとメモリーフットプリントを向上させることができます。

開発時のライブリロード

静的モジュールは自動的に監視され、リロードされます。誰もがお気に入りの quarkus:dev を、Rust や Go のモジュールでも利用できると考えてください。

Native Image 互換性
WASM/WASI サポート

このポテンシャルを手に、我々はいくつかの Go オペレーターで採用されている人気の高い Google CEL (Go ライブラリー/API) を選択し、アプリケーションに統合することにしました。

アプリケーションのセットアップと設定

アプリケーションの作成は、Quarkus Maven プラグインを使用して簡単に行えます。Quarkus 3.x には Java 17 以上が必要であることに注意してください (この例では Java 21 を使用しました)。

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

次に、Quarkus Chicory エクステンションを 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>

最後に、WASM モジュールの設定を 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

これにより、Quarkus Chicory に対して、指定された WASM ファイルからビルド時に GoCelModule クラスを生成するように指示します。エクステンションは、WebAssembly モジュールから Java バイトコードを自動的に生成し、実行環境に基づいて適切な MachineFactory を構成し、開発モードでは WASM ファイルの変更を監視してライブリロードをトリガーします。

最後のステップです。 WasmModuleInterface アノテーションを使用し、アノテーションプロセッサーを設定します。これにより、Chicory は Go のエクスポートされた関数と 1:1 でマッピングされるメソッドを含む Java クラスを生成します。

まず、アノテーションを配置する K8sCel Java クラスを作成しましょう。

package io.quarkiverse.chicory.demo;

import com.dylibso.chicory.annotations.WasmModuleInterface;

@WasmModuleInterface(WasmResource.absoluteFile)
public class K8sCel {

    private K8sCel() {}

}

ビルド時に、Chicory アノテーションプロセッサーはこのアノテーションを検出し、エクスポートされたメソッドを提供する K8sCel_ModuleExports クラスを生成します。

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;
    }
}

これだけで十分です！

`WasmQuarkusContext` API

このサンプルアプリケーションは、関心事が分離されたクリーンアーキテクチャパターンに従っています。

K8sCelValidatorService - WASM 統合とビジネスロジックを管理
K8sCelValidatorResource - REST API エンドポイントを提供

Quarkus Chicory エクステンションは、設定された WASM モジュールにアクセスするためのインジェクション用 WasmQuarkusContext API を提供します。サービスでの使用方法は次のとおりです。

@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	インジェクトされた `WasmQuarkusContext` Bean は、アプリケーションの設定と実行環境に基づいて動的に作成される `MachineFactory` および `WasmModule` インスタンスを使用するように `Instance.Builder` を構成します。
2	`instance` が構築されると、 `export` は `K8sCel_ModuleExports` インスタンスで初期化され、後に `validate()` メソッドで呼び出されるエクスポート関数を提供します。
3	Go ランタイムを初期化するために、エクスポートされた "_start" 関数が呼び出されます。これにより、Go プログラムの `main()` 関数が実行されます。今回の実装では中身が空であるため、すぐに終了します。そのため、 `WasiExitException` をキャッチして、終了コードが 0 (エラーなし) であることを確認します。

マルチユーザーとスレッドセーフに関する注意

WasmQuarkusContext インスタンスは @ApplicationScoped Bean としてインジェクトされます。これは、単一のアプリケーションインスタンスが複数のクライアント (またはユーザーリクエスト) やスレッドによって使用される可能性があることを意味します。とはいえ、API の実装は ステートレス であり、 getMachineFactory() と getWasmModule() は常に新しいインスタンスを返します。

これらのインスタンスの扱い方やライフサイクルのオーケストレーション方法は、アプリケーションドメインに属する事項です。例えば、上記のターゲット実装は並行性を考慮していません。複数のスレッドが同じ Memory インスタンスを消費する場合、共有されている WasmModule の線形メモリーの破損を避けるために、スレッドセーフな実装が必要になります。

アプリケーションコードに戻ると、REST リソースは単純な委譲レイヤーとなります。

@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();
    }
}

WasmQuarkusContext API は、2 つの主要なメソッドを提供します。

getWasmModule(): 解析された WebAssembly モジュールを返します。
getMachineFactory(): 環境に基づいた適切な MachineFactory を返します (開発時はインタープリター、本番/ネイティブ時はビルド時コンパイル)。

@Named 修飾子は、application.properties のモジュール名と一致します。エクステンションが WASM モジュールのライフサイクルの複雑さをすべて処理するため、開発者はビジネスロジックに集中できます。

仕組み: Go → Wasm → Java バイトコード

アプリケーションの核心は、WebAssembly にコンパイルされた Go CEL 実装です。Go コードは、3 つの主要なエクスポート関数を実装しています。

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

この Go コードは、WASI ターゲットを使用して WASM にコンパイルされます。

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

サービスの実装において:

Java はポリシー文字列と入力リソースマニフェスト (JSON) 用に WASM メモリーを割り当て、データを WASM メモリーに書き込みます。
Java は、引数へのポインターとそのサイズを指定して evalPolicy() を呼び出します。
Go コードはそのメモリー空間から読み取り、Google CEL ライブラリーを使用して CEL 式を評価します。
Go は整数の結果コードを返します (1=許可、0=拒否、負の値=エラー)。
Java は結果を解釈し、クリーンアップを実行します。

これは WebAssembly のパワーを示しています。成熟し、十分にテストされた Google CEL-Go ライブラリーを、CEL を一から再実装することなく Java から使用できるのです。

WASM の境界は、2 つの言語間にクリーンで安全なインターフェースを提供します。

本番環境では、Go オペレーターと同じように Kubernetes リソースを検証する CEL ポリシーを記述できます。

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

結論

Quarkus Chicory と、WebAssembly にコンパイルされた Google CEL-Go を組み合わせることで、完全に Java で動作する Kubernetes スタイルの CEL ポリシーエンジンを作成しました。

このアプローチにはいくつかの利点があります。

既存の Go ライブラリーの再利用: Java で CEL を再実装する必要がなく、オリジナルの Go コードと 1:1 で対応します。
型安全性とパフォーマンス: Quarkus Chicory が WASM モジュールから Java バイトコードを生成します。
本番環境への対応: Go オペレーターで使用されているものと同じ CEL ライブラリーが、Java でも利用可能になります。
開発者体験: ライブリロード、ビルド時のコード生成、および Native Image サポート。
エコシステムの互換性: Java ベースの Kubernetes オペレーターとシームレスに連携します。

これは、WebAssembly が単なるブラウザー技術ではなく、クラウドネイティブアプリケーションにおける言語間相互運用のための強力なツールであることを示しています。また、Quarkus Chicory のおかげで、このワークフローを Quarkus アプリケーションに簡単に統合できることも実証されました。

Kubernetes オペレーターを構築する Java 開発者にとって、このアプローチは JVM を離れることなく Go エコシステムの大部分を活用する道を切り開きます。

完全な動作例は、こちらで確認できます。 https://github.com/fabiobrz/quarkus-cel-k8s-validator

参照

Quarkus 3.31.4 - メンテナンスリリース

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

本日、3.31 ストリーム向けの3回目のメンテナンスリリースである Quarkus 3.31.4 をリリースしました (3.31.0 はスキップしました)。

Update

Quarkus 3.31 に更新するには、Quarkus CLI の最新バージョンに更新して、以下を実行することを推奨します:

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.31 へアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.31 マイグレーションガイドを参照してください。

完全な変更履歴

3.31.4 の完全な変更履歴は GitHub で確認できます。

参加のお誘い

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

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

Quarkusニュースレター #65 - 2月

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

Quarkusはマイクロサービスに重点を置いていますが、既存のアプリケーションをよりモダンなランタイムに移行する場合でも、新しいアプリケーションをゼロから構築する場合でも、大規模なモノリスにも完全に適しています。Quarkusは常に大規模なアプリケーションを処理できましたが、特にビルド時間に関しては、この分野で最近大幅な改善を行いました。これらの改善の詳細については、Guillaume Smetによる「Towards faster builds (より高速なビルドに向けて)」をお読みください。Guillaume Laforgeによる「Implementing an arXiv MCP Server with Quarkus in Java (QuarkusとJavaでarXiv MCPサーバーを実装する)」を読んで、事前公開版がコミュニティと共有されるarXiv研究論文ウェブサイトにアクセスするためのMCPサーバーの構築について学びましょう。著者の目標は、Model Context Protocolのあまり知られていない側面、ツール、リソース、プロンプトに光を当てることでした。Anand Jaisyが「Micronaut vs Quarkus: Why I Switched After Two Years (Micronaut vs Quarkus: 2年後にフレームワークを切り替えた理由)」でフレームワークを切り替えることを選んだ理由の詳細を学びましょう。Nawaz Dhandalaによる「How to Trace Quarkus Reactive Messaging with OpenTelemetry (OpenTelemetryでQuarkus Reactive Messagingをトレースする方法)」をチェックして、OpenTelemetryを使用してKafkaやその他のメッセージングシステム間でメッセージを追跡するためのQuarkus Reactive Messagingアプリケーションの分散トレースを実装する方法を学びましょう。Markus Eiseleによる「Your Second Reactive Messaging App: What Production Systems Actually Need (あなたの2番目のリアクティブメッセージングアプリ: 生産システムが実際に必要とするもの)」で、バリデーション、再試行、冪等性、Kafkaを活用したワークフローをQuarkusで示すこの実践的なJavaウォークスルーをぜひ試してみてください。次に、彼の2番目のブログ投稿「Your Quarkus Architecture Is Drifting. JQAssistant Can Prove It. (あなたのQuarkusアーキテクチャは漂流している。JQAssistantがそれを証明できる。)」で、グラフベースの分析を使用してJavaアプリケーションのアーキテクチャの劣化を検出および防止する方法について学ぶことができます。

最新のQuarkus Insightsエピソード、トップツイート/ディスカッション、今後開催されるQuarkus参加イベントもご覧いただけます。

ニュースレター #65: 2月をチェックしてください！

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

A2A Java SDK 1.0.0.Alpha2 リリース

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

A2A Java SDK 1.0.0.Alpha2 のリリースをお知らせします。このリリースでは、 A2A 1.0 仕様への準拠を継続し、重要な新機能と改善が導入されています。

A2A とは

1.0.0.Alpha2 における主なハイライト

このリリースには、いくつかの重要な機能強化と破壊的変更が含まれています。

新機能

テレメトリーのサポート

A2A Java SDK に、OpenTelemetry を使用したテレメトリーのサポートが組み込まれました。これにより、エージェントの操作を監視およびトレースできるようになり、問題の診断やパフォーマンス特性の把握が容易になります。

テレメトリー機能を使用するには、プロジェクトに OpenTelemetry エクストラを追加します。

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

プッシュ通知

A2A 1.0 仕様で規定されているプッシュ通知を完全にサポートしました。これにより、エージェントはポーリングを行うことなくタスクの更新通知を受け取ることができます。

サーバーエージェントで以下のことが可能になりました。

プッシュ通知エンドポイントの設定
タスクごとのプッシュ通知設定の管理
タスクの状態が変化した時の通知の受信

クライアントで以下のことが可能になりました。

プッシュ通知設定の取得、設定、一覧表示、および削除
プッシュ通知によるタスク更新の購読

プロトコルのアップデート

破壊的変更

このリリースには、最新の A2A 仕様に準拠するための破壊的変更が含まれています。

AgentEmitter API: AgentExecutor メソッドは、従来の EventQueue と TaskUpdater の組み合わせの代わりに AgentEmitter を使用するようになり、より合理化され直感的な API が提供されます。この機能強化により、単純なエージェント間のやり取りのためのメッセージを AgentEmitter 経由で直接送信できるようになり、EventQueue を直接操作する必要がなくなりました。
プロトコルの整合性: gRPC プロトコル定義の更新を含む、最新の仕様改訂に合わせるために A2A プロトコルの実装を更新しました。

その他の改善点

Null 安全性: spec モジュールを JSpecify アノテーションを使用するように移行し、より優れた Null 安全性を保証しました。
Jakarta CDI 互換性: Jakarta CDI の互換性を向上させるために、引数なしのコンストラクターを追加しました。
HTTP+JSON/REST トランスポート: 統合を改善するために、 quarkus-rest-jackson を quarkus-rest に置き換えました。
イベント処理: より堅牢なイベントキュー処理を実現するために、 MainEventBus アーキテクチャーを実装しました。
MicroProfile Config: microprofile-config 統合に欠落していた META-INF/beans.xml を追加しました。

移行ガイド

1.0.0.Alpha1 からアップグレードする場合は、以下の変更を行う必要があります。

AgentExecutor 実装の更新

execute および cancel メソッドは、 EventQueue の代わりに AgentEmitter パラメーターを受け取るようになりました。

// 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();
    // ...
}

AgentEmitter インターフェースは、よりクリーンな API で同等の機能を提供します。

はじめに

A2A Java SDK 1.0.0.Alpha2 を使用するには、プロジェクトに適切な依存関係を追加してください。

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

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

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

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

リソース

まとめ

A2A Java SDK 1.0.0.Alpha2 は、完全な A2A 1.0 仕様準拠への道のりにおける重要な前進です。テレメトリーサポートとプッシュ通知の追加により、本番環境に対応したエージェントの構築が容易になり、プロトコルのアップデートによって最新の仕様との互換性が確保されます。

このリリースをぜひお試しいただき、 GitHub イシュートラッカーを通じてフィードバックをお寄せください。皆様からの入力が A2A Java SDK の将来を形作る助けとなります。

Quarkus 3.31.3 - メンテナンスリリース

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

本日、Quarkus 3.31ストリームの2番目のメンテナンスリリースである Quarkus 3.31.3 をリリースしました (3.31.0 はスキップしました)。

Update

Quarkus 3.31 に更新するには、Quarkus CLI の最新バージョンに更新して、以下を実行することをお勧めします。

quarkus update

なお、quarkus update を使用すると、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.31 へアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.31 移行ガイドを参照してください。

完全な変更履歴

3.31.3 の完全な変更履歴は GitHub で入手できます。

参加のお誘い

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

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

ギャップを埋める：Quarkus エクステンションのテストカバレッジ

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

テストカバレッジは通常、テストによって実行されたコードの割合を測定する指標として定義されます。その有用性を疑う開発者もいますが、私は「テストカバレッジは、コードベースのテストされていない部分を見つけるための有用なツールである」という Martin Fowler 氏の意見に同意します。算出される数値自体が重要だとは思いません。結局のところ、生成された getter のテストを書くことには全く意味がありません。しかし、エクステンションのホットパスにおいてテストが不十分なコードを特定できれば、テストスイートを改善し、リリース前にバグを発見することができます。これは常に報われる作業です。同様に重要なこととして、リグレッションを捕捉する能力を高めることもできます。

長い間、https://www.jacoco.org/jacoco/index.html[JaCoCo コードカバレッジライブラリー]を統合する io.quarkus:quarkus-jacoco エクステンションが存在していました。しかし、最近まではエクステンションプロジェクトのランタイムモジュールのカバレッジを測定することは不可能でした。言い換えれば、@QuarkusTest ではカバレッジを測定できましたが、エクステンションのテストの大部分を占めるのが一般的な QuarkusUnitTest では測定できなかったのです。適切なカバレッジサポートがなければ、開発者は自身のバイトコード拡張やレコーディングロジックが効果的にテストされているかどうか確信が持てず、手探りの状態でした。

技術的な概要

JaCoCo は実行カバレッジデータを記録するためにクラスをインストゥルメントします。デフォルトでは、クラスは Java エージェントによってオンザフライでインストゥルメントされます。しかし、Quarkus ではオフラインインストゥルメンテーションを使用して、ビルド中にクラスのバイトコードを修正します。デフォルトでは、すべてのアプリケーションアーカイブ内のすべてのクラスがインストゥルメントされます。アプリケーションアーカイブとは、アプリケーションにコンポーネントを提供するアーカイブのことです。これは Jandex を介してインデックス化され、エクステンションはその内容を分析できます。例えば、Quarkus は CDI Bean の検出中にアプリケーションアーカイブを分析します。しかし、エクステンションのランタイムモジュールは通常、アプリケーションアーカイブではありません。そのため、エクステンションのクラスはインストゥルメントされませんでした。今までは。Quarkus 3.31.2 では、インストゥルメントするアーティファクトを指定する新しい設定プロパティー quarkus.jacoco.instrument-artifacts."dependency-name".group-id と quarkus.jacoco.instrument-artifacts."dependency-name".artifact-id が導入されました。

基本設定

エクステンションのランタイムモジュールのテストカバレッジを測定したい場合は、デプロイメントモジュールで特定の JaCoCo 設定が必要になります。

<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	このプロファイルは `jacoco` プロパティーによって有効化されます。
2	テストスコープで `quarkus-jacoco-deployment` 依存関係を追加します。
3	`io.quarkus:quarkus-runtime-module-name` アーティファクトをインストゥルメントするように JaCoCo プラグインに指示します。

デフォルトでは、JaCoCo データは target/jacoco-quarkus.exec ファイルに保存され、カバレッジレポートは target/jacoco-report ディレクトリに自動的に生成されます。

マルチモジュール設定

マルチモジュールプロジェクトの場合、さらに多くの設定プロパティーが必要になる場合があります。通常、エクステンションプロジェクトに互いに依存する複数のエクステンションが含まれている場合、より複雑な設定が必要になります。以下のプロジェクトでは、foo と bar という 2 つのエクステンションサブモジュールがあります。

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

サブモジュール bar は foo に依存し、その機能を拡張します。foo/deployment サブモジュールには、foo/runtime のクラスをテストする QuarkusUnitTest が含まれています。bar/deployment サブモジュールには、bar/runtime と foo/runtime の両方のクラスをテストする QuarkusUnitTest が含まれています。

私たちの目標は、foo/runtime と bar/runtime の両方のカバレッジを測定することです。どのように進めればよいでしょうか。まず、親プロジェクトにいくつかの設定を適用する必要があります。

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	このプロファイルは `jacoco` プロパティーによって有効化されます。
2	共有される JaCoCo データファイルは `my-extension-project/target/jacoco.exec` になります。
3	共有された JaCoCo データはすべてのテストで再利用されます。
4	生成されるカバレッジレポートは `my-extension-project/target/coverage` ディレクトリに出力されます。
5	レポートデータ (ソースディレクトリとクラスファイル) は、単一のレポートを生成できるように集計されます。

その後、foo と 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	このプロファイルは `jacoco` プロパティーによって有効化されます。
2	`bar/deployment` でテストを実行する際に `org.acme:foo` をインストゥルメントします。
3	`bar/deployment` でテストを実行する際に `org.acme:bar` をインストゥルメントします。

同様に my-extension-project/foo/pom.xml を修正し、mvn clean test -Djacoco を実行するだけです。ビルドが完了すると、my-extension-project/target/coverage ディレクトリにあるコードカバレッジレポートを分析できます。

Quarkus の JaCoCo 設定は、@QuarkusTest または @QuarkusUnitTest のアノテーションが付いたテストに対してのみ機能します。それ以外のテストのカバレッジも確認したい場合は、JaCoCo Maven プラグインにフォールバックする必要があります。詳細については、https://quarkus.io/guides/tests-with-coverage#coverage-for-tests-not-using-quarkustest[ドキュメント]を参照してください。

まとめ

Quarkus 3.31.2 以降、Quarkus エクステンションのランタイムモジュールのコードカバレッジを測定し、分析できるようになりました。テストスイートを改善し、リリース前に多くのバグを発見し、より多くのリグレッションを捕捉しましょう。

Quarkus 3.31.2 - メンテナンスリリース

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

本日、3.31 ストリームで最初のメンテナンスリリースである Quarkus 3.31.2 をリリースしました (3.31.0 はスキップしました)。

Update

Quarkus 3.31 にアップデートするには、Quarkus CLI の最新バージョンにアップデートして、以下を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus のあらゆるバージョン (2.x を含む) から Quarkus 3.31 にアプリケーションをアップデートできます。

アプリケーションに必要な調整に関する詳細情報については、 Quarkus 3.31 移行ガイドを参照してください。

完全な変更履歴

3.31.2 の完全な変更履歴は GitHub で確認できます。

参加のお誘い

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

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

Quarkus 3.31 - フルJava 25サポート、Quarkus Mavenパッケージング、Panache Next、その他！

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

前回の機能リリースから2ヶ月が経ち、Quarkus 3.31の提供開始を発表できることを嬉しく思います！

Quarkus 3.31には、多くの新機能と改善が含まれています:

フルJava 25サポート
#51587 - Quarkus Mavenパッケージングと関連するライフサイクルの導入
#50058 - 開発者エクスペリエンスが向上し、Hibernate ORMとHibernate Reactiveの両方に新機能が追加された次世代PanacheであるPanache Nextの導入
#50519 - Hibernate ORM 7.2、Reactive 3.2、Search 8.2、クライアント/サーバー向けElasticsearch 9.2 / OpenSearch 3.3 (dev services) へのアップグレード
#51586 - Hibernate Spatial のサポート
#51314 - Testcontainers 2 へのアップグレード
#51412 - JUnit 6 へのアップグレード
#50987 - Jakarta Data リポジトリーにおけるセキュリティアノテーションのサポート
#51188 - REST Data Panache エンドポイントでの @PermissionsAllowed セキュリティアノテーションのサポート
#51220 - カスタム TokenStateManager 実装向けのOIDCトークンの暗号化
#51383 - トークン向けのOIDC DBトークンステートマネージャーカラムサイズの設定を許可
#51743 - 個々の動的GraphQLクライアント向けOIDCクライアントの選択を許可
#51679 - スケジュールされたタスクにユーザーとロールを割り当てることを許可
#51799 - OIDCエクステンションへのOAuth 2.0 Pushed Authorization Requestsのサポート追加
#50603 - ネイティブイメージ向けWindowsでのヘッドレスAWTの有効化
#51736 - QuarkusプロジェクトにはMaven 3.9.0+を要求
#51049 - Dev UIにi18nを追加

いつものように、このリリースには、素晴らしいコミュニティーのおかげで、 2020年に作成された非常に古い問題の修正を含む、多くのバグ修正も含まれています！

このバージョンにはいくつかの重要な変更が含まれているため、移行ガイドを参照することを強くお勧めします。

Update

Quarkus 3.31に更新するには、Quarkus CLIの最新バージョンに更新して、以下を実行することをお勧めします:

quarkus update

quarkus update は、Quarkusの任意のバージョン（2.xを含む）からQuarkus 3.31にアプリケーションを更新できることに注意してください。

アプリケーションに行う必要がある調整の詳細については、 Quarkus 3.31移行ガイドを参照してください。

変更点

Java 25のフルサポート

Quarkus 3.31は、Java 25ランタイムイメージおよびMandrelを使用したネイティブイメージビルドを含む、Java 25のフルサポートを追加します。

Java 25で新しいプロジェクトを作成すると、プロジェクトはデフォルトでJava 25を完全にターゲットとします。

Java 25でQuarkusアプリケーションを実行する際の互換性を確保し、可能な限り多くの警告を回避するために懸命に取り組みました。そこに表示されるべきではない警告を含む問題に遭遇した場合は、バグトラッカーに報告してください。

新しいQuarkus Mavenパッケージングとライフサイクル

数ヶ月前、私たちはビルドを高速化することに取り組み始めました（詳細については、このブログ記事を参照してください）。Quarkus 3.31では、より統合され、大幅に効率的なビルドライフサイクルを提供するように設計された、 quarkus と呼ばれる新しいMavenパッケージングタイプを導入しています。

言い換えれば、私たちはデフォルトのMaven jar ライフサイクルから離れ、Quarkusアプリケーションに最適化されたQuarkus固有のライフサイクルを導入し、ほとんどの場合に不要なゴールの実行を回避します。

これは新しく作成されるQuarkusプロジェクトのデフォルトであり、既存のプロジェクトでも使用できます（詳細については、移行ガイドを参照してください）。

大規模なアプリケーション

この「高速ビルド」の取り組みは、大規模なアプリケーションにとって特に有益であり、非常に大規模なアプリケーションを作成する際の最新のボトルネックの1つを軽減しました。それは、アプリケーション内のCDI Beanの数がビルド中にクラスファイルの制限に達する可能性があったことです。

Quarkus 3.31では、CDI Beanの数によって制限されることはもうありません。

Panache Next

QuarkusでHibernate ORMを使用している場合、おそらくHibernate ORM with Panacheについてはすでにご存知でしょう。

Panache Nextは、より良い開発者エクスペリエンスと新機能をもたらす次世代のPanacheです。現在のPanache実装と同じ基盤となる概念に依拠しつつ、Panache Nextはより直感的なAPI、改善された型安全性、および強化されたクエリ機能を提供します。また、Hibernate ORMとHibernate Reactive、ステートフルおよびステートレスセッション間のプログラミングモデルを統一し、開発者がそれらを簡単に切り替えられるようにします。最後に、Jakarta Dataとシームレスに統合されます。

さらに多くのことを言うべきですが、最善はドキュメントを見て試してみることです。

これはまだ実験的な段階であり、皆様からのフィードバックをお待ちしております。

Hibernate ORM

Quarkus 3.31は、Hibernate ORMを7.2、Hibernate Reactiveを3.2、Hibernate Searchを8.2、Elasticsearch/OpenSearchクライアントおよびサーバーをそれぞれ9.2/3.3にアップグレードします。

また、Hibernate Spatialのサポートも導入され、開発者はQuarkusアプリケーションで空間データ型を操作し、空間クエリを実行できるようになります。

JUnit 6とTestcontainers 2

JUnit 6（更新は比較的簡単）とTestcontainers 2（より多くの破壊的変更を伴う）にアップグレードしました。

quarkus-junit5 エクステンションは -junit に名前が変更されました。既存のプロジェクトを壊さないようにリロケーションが設定されています。 quarkus update を使用して自動的に更新してください。

セキュリティー

セキュリティの改善なしにQuarkusリリースがあるでしょうか？

このリリースには、当社のセキュリティエクステンションに対する多くの改善が含まれており、以下を含みます:

#50987 - Jakarta Data リポジトリーにおけるセキュリティアノテーションのサポート
#51188 - REST Data Panache エンドポイントでの @PermissionsAllowed セキュリティアノテーションのサポート
#51220 - カスタム TokenStateManager 実装向けのOIDCトークンの暗号化
#51383 - トークン向けのOIDC DBトークンステートマネージャーカラムサイズの設定を許可
#51743 - 個々の動的GraphQLクライアント向けOIDCクライアントの選択を許可
#51679 - スケジュールされたタスクにユーザーとロールを割り当てることを許可
#51799 - OIDCエクステンションへのOAuth 2.0 Pushed Authorization Requestsのサポート追加

Maven 3.9が必須

Quarkusアプリケーションをビルドするには、Maven 3.9が必須になりました。

ネイティブイメージでのWindowsにおけるヘッドレスAWT

AWTエクステンションに、ネイティブイメージでのWindowsにおけるヘッドレスAWTのサポートを追加しました。

Dev UIのI18N

Dev UIが国際化されました。

翻訳の改善や新しい言語の追加への貢献を歓迎します。

完全な変更履歴

3.31.0.CR1 、 3.31.0 、および 3.31.1 の完全な変更履歴はGitHubで確認できます。

コントリビューター

Quarkusコミュニティは成長を続けており、現在 1153名の貢献者がいます。各貢献者の皆様に深く感謝いたします。

特に3.31リリースでは、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、およびYoann Rodièreに感謝いたします。

参加のお誘い

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

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

Quarkus 3.30.8 - メンテナンスリリース

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

本日、Quarkus 3.30 ストリームの新しいメンテナンスリリースである Quarkus 3.30.8 をリリースしました。

これは、3.30.7 で導入された OpenTelemetry および MDC データ伝播に影響を与えるリグレッションを修正します。

Update

Quarkus 3.30 に更新するには、Quarkus CLI の最新バージョンに更新し、以下のコマンドを実行することをお勧めします。

quarkus update

quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.30 へアプリケーションを更新できることに注意してください。

アプリケーションに必要な調整の詳細については、 Quarkus 3.30 migration guide を参照してください。

完全な変更履歴

3.30.8 の完全な変更ログは GitHub で確認できます。

参加のお誘い

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

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

Quarkus 用コミュニティ版 UBI 8 イメージの提供終了

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

ご存知の通り、Quarkus はアプリケーションのビルドと実行の両方のために、Red Hat Universal Base Image (UBI) をベースにしたコンテナーイメージを提供しています。

Quarkus 3.19 以降、Quarkus はコンテナーイメージのデフォルトベースイメージとして UBI 9 を使用しています。コミュニティでメンテナンスしている最古のバージョンが 3.20 LTS であることを踏まえ、2026年3月に Quarkus 用コミュニティ版 UBI 8 イメージの提供を終了することを決定しました。

コミュニティの Quay リポジトリーからイメージを削除することはありませんが、それらのイメージは今後更新されません。これは、UBI 8 に影響を与える CVE の問題が、コミュニティ版 Quarkus UBI 8 イメージでは今後修正されないことを意味します。

Quarkus アプリケーションのビルドまたは実行にまだ UBI 8 イメージを使用している場合は、できるだけ早く UBI 9 ベースのイメージに移行することを強くお勧めします。UBI 8 に留まる必要がある特定の理由がある場合は、お問い合わせください。

参加のお誘い

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

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

Quarkus 3.30.7 - メンテナンスリリース

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

本日、Quarkus 3.30.7 をリリースしました。これは 3.30 ストリームの新しいメンテナンスリリースで、いくつかの追加修正と Vert.x のマイクロアップデートが含まれています。

Quarkus 3.31 は来週リリースされます。2か月にわたる作業の成果ですので、多数の新機能と改善が期待されます！

Update

Quarkus 3.30 に更新するには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.30 へとアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.30 移行ガイドを参照してください。

完全な変更履歴

3.30.7 の完全な変更ログは GitHub で入手できます。

参加のお誘い

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

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

Quarkus 3.27.2 がリリースされました - LTS メンテナンスリリース

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

本日、Quarkus 3.27.2 をリリースしました。これは 3.27 LTS ストリームの次のメンテナンスリリースです。

このリリースには、バグ修正、ドキュメントの更新、および以下の CVE の修正が含まれています。

3.27 をすでに使用している方にとっては、安全にアップグレードできます。

Update

Quarkus 3.27 に更新するには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします。

quarkus update --stream=3.27

quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.27 にアプリケーションを更新できます。

完全な変更履歴

3.27.2 の完全な変更履歴を GitHub で取得できます。

参加のお誘い

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

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

Quarkus 3.20.5 リリース - LTS メンテナンスリリース

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

本日、Quarkus 3.20.5 をリリースしました。これは 3.20 LTS ストリームの次期メンテナンスリリースです。

このリリースには、バグ修正、ドキュメントの更新、および以下の CVE に対する修正が含まれています。

3.20 を既に使用している方にとっては、安全なアップグレードとなるはずです。

Update

Quarkus 3.20 に更新するには、Quarkus CLI の最新バージョンに更新し、以下を実行することをお勧めします。

quarkus update --stream=3.20

quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.20 へアプリケーションを更新できることに注意してください。

完全な変更履歴

3.20.5 の完全な変更ログは GitHub で入手できます。

参加のお誘い

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

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

A2A Java SDK 1.0.0.Alpha1 - 1.0仕様への対応

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

A2A Java SDK 1.0.0.Alpha1 のリリースを発表できることを嬉しく思います。このリリースは、今後の1.0バージョンの Agent2Agent (A2A) プロトコル仕様に対応する重要なマイルストーンとなります。なお、仕様自体はまだ最終決定段階にあるため、最終的な1.0バージョンまでにいくつかの微妙な変更がある可能性があります。

A2Aプロトコルは、AIエージェント間の標準化された通信を可能にし、エージェントが機能を検出し、タスクを委任し、シームレスに連携できるようにします。このSDKは、A2Aエコシステムに参加するエージェントとクライアントの両方を構築するための堅牢なJava実装を提供します。

1.0が重要である理由

A2A仕様のバージョン1.0への移行は、実験段階から製品対応への移行を示します。仕様が成熟するにつれて、当社は技術的負債を整理し、実装を近代化し、将来にわたって役立つパターンを確立する機会を得ました。

このリリースには破壊的な変更が含まれています。 1.0が仕様の最初の「正式な」リリースであるため、当社は0.3.xシリーズとの後方互換性を維持しないという意図的な決定をしました。これにより、レガシーパターンを引き継ぐことなく、強固な基盤の上に構築できます。

主な変更点

1. 仕様への対応

SDKは現在、プロトコルバージョン 1.0 を実装し、最新の a2a.proto 定義に対応しています。主な仕様変更は以下のとおりです。

AgentCardの進化: AgentCard は、個別の url、preferredTransport、additionalInterfaces フィールドの代わりに、supportedInterfaces リストを使用するようになりました。これにより、複数のプロトコルバインディングを宣伝するための、よりクリーンで柔軟な方法が提供されます。
種類識別子の削除: 1.0仕様では、kind フィールドを型識別子として廃止し、プロトコルを簡素化しました。
エラーハンドリングの改善: エラークラスは、1.0仕様のエラーモデルに合うように再設計されました。

2. モダンJava: レコードへの標準化

spec モジュール全体が、Javaレコードを継続的に使用するように近代化されました。以前は、ドメインモデル全体で従来のクラスとレコードが混在していました。現在、すべてのドメインクラスは不変性と簡潔さのためにレコードを活用し、すべてのゲッターは同じ命名パターンに従います。

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

この標準化により、混乱が解消され、ボイラープレートが削減されるとともに、よりクリーンで保守しやすいAPIが提供されます。

A2A Java SDKは、過去数ヶ月にわたるJSpecifyアノテーションの段階的な採用を通じて、型安全性と **null安全** において大幅な改善がみられました。この取り組みは、コード品質に対するプロジェクトのコミットメントと、コンパイル時におけるNullPointerExceptionの防止を示しています。

静的ファクトリーメソッドを使用したビルダーパターン

すべてのビルダーは、パブリックコンストラクターの代わりに静的ファクトリーメソッドを使用するようになりました。これにより、カプセル化が向上し、最新のJavaのベストプラクティスに従うことができます。

// 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()` がビルダーを作成します — コンストラクターは現在プライベートです
2	ネストされたビルダーも静的ファクトリーメソッドを使用します
3	すべての仕様クラスは、このパターンを一貫して踏襲しています

ビルダーコンストラクターは、宣言クラスで現在プライベートであり、SDK全体で静的ファクトリーメソッドパターンの使用を強制しています。

3. Protocol Buffersを信頼できる唯一の情報源として

Jacksonへの依存を排除し、プロトコルバッファ (protobuf) をドメインモデルの信頼できる唯一の情報源として確立しました。アーキテクチャは次のとおりです。

Protobuf定義 は a2a.proto でワイヤーフォーマットを定義します
Javaレコード は spec モジュールでSDKのAPIを提供します
MapStructマッパー は変換を処理し、protobufと仕様クラスの同期が外れた場合にコンパイルエラーを発生させます
Gson はJSON-RPCトランスポートのJSONシリアライゼーションを処理します

これにより、すべてのトランスポートで型安全性、プロトコルの信頼できる唯一の情報源、およびシリアライゼーションアノテーションでドメインクラスを煩雑にすることなく、ワイヤーフォーマットとAPIのクリーンな分離が提供されます。

4. 部品表 (BOM)

依存関係管理を簡素化するためにMaven BOMを導入しました。

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

3つのBOMが利用可能です。

a2a-java-sdk-bom: コアSDKおよびクライアントライブラリ
a2a-java-extras-bom: オプションの拡張機能 (JpaDatabaseTaskStore および -PushNotificationStore、レプリケートされたQueueManager、Vert.X HTTPクライアント)
a2a-java-reference-bom: Quarkusリファレンス実装

これにより、複数のSDKモジュールとその依存関係を使用する際のバージョン管理の悩みを解消します。

5. APIドキュメントの強化

spec モジュール内のすべてのクラスには、その目的、使用法、およびA2A仕様との関係を説明する包括的なJavadocが含まれるようになりました。また、server-common およびすべてのクライアントモジュールにおける統合ポイントの詳細なドキュメントも追加しました。

6. 追加の改善点

ページネーションのサポート: ListTasks およびプッシュ通知設定エンドポイントは、適切な Result ラッパーを使用したページネーションをサポートするようになりました
プラガブルHTTPクライアント: 新しい A2AHttpClient インターフェースはカスタムHTTP実装を可能にし、Vert.xベースの実装が提供されています
より良い検証: すべてのトランスポートで入力検証を強化しました
TCKの進捗: 1.0 Test Compatibility Kitへの完全な準拠に向けた継続的な取り組み。仕様が最終決定段階にある間、TCKも進行中です。

破壊的な変更の概要

0.3.xから移行する場合、主な破壊的な変更点は次のとおりです。

AgentCard構造: url + preferredTransport を supportedInterfaces リストに置き換える
ビルダーパターン: new AgentCard.Builder() の代わりに AgentCard.builder() を使用する — すべての仕様クラスに適用されます
プロトコルバージョン: AgentCard.CURRENT_PROTOCOL_VERSION (現在 "1.0") に更新する
フィールド名の変更: supportsAuthenticatedExtendedCard → supportsExtendedAgentCard
ゲッターの命名: レコードは card.getName() の代わりに card.name() を使用します
パッケージのクリーンアップ: io.a2a.apec パッケージはトリミングされました
シリアル化: Jackson のアノテーションに依存していた場合は、Gson パターンに移行してください

はじめに

Maven を使用して、BOM と依存関係を追加します。

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

エージェントの作成には、AgentCard と AgentExecutor の生成が必要です。@PublicAgentCard 修飾子は、検出のエントリポイントとして機能する公開エージェントカードをマークします。これは、クライアントがエージェントを検出する際に取得するものです。また、追加の認証情報を含む拡張エージェントカードを提供することもできます。以下に最小限の例を示します。

@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();
        }
    }
}

完全な例については、リポジトリ内の Hello World の例を参照してください。

今後の展望

このアルファ版リリースにより、安定版の 1.0 SDK に大きく近づきました。今後のリリースにおける主要な焦点は以下のとおりです。

1.0 TCK テストスイートへの完全な準拠
実世界の利用状況に基づいたパフォーマンスの最適化
追加の例と統合ガイド
シームレスな Jakarta EE 統合のための WildFly Feature Pack

A2A 仕様自体も 1.0 リリースに向けて進化を続けています。私たちは仕様策定プロセスに積極的に参加しており、仕様が最終化されるにつれて SDK の調整を継続していきます。

参加する

貢献、フィードバック、実世界の利用状況レポートを歓迎します。AI エージェントを構築している方や、マルチエージェントアーキテクチャを検討している方にとって、A2A Java SDK は堅牢な基盤を提供します。

リポジトリ: https://github.com/a2aproject/a2a-java
例: https://github.com/a2aproject/a2a-java/tree/main/examples
仕様: https://github.com/a2aproject/A2A
課題: https://github.com/a2aproject/a2a-java/issues

1.0.0.Alpha1 を試して、エージェントのユースケースにどのように機能するかをお知らせください。

Quarkus ニュースレター #64 - 1月

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

Markus Eisele による素晴らしい記事「Why Quarkus Finally “Clicks”: The 10 Questions Java Developers Ask Most」をご覧ください。これは、カンファレンスやミートアップ、The Main Thread コミュニティでの実際の会話に基づいた優れたフィールドガイドです。Stéphane Épardaud による「Quarkus Hibernate with Panache Next」を読んで、Hibernate ORM with Panache と Hibernate Reactive with Panache の両方を統合する新しい Hibernate with Panache エクステンションについて学びましょう。モダンでデータ指向のアプリケーション設計に関する完全なハンズオンチュートリアルが必要ですか？Markus Eisele が「Build Event-Sourced Systems in Quarkus with Java Records and CQRS」でその方法を解説しています。Stéphane Philippart のブログ投稿をチェックして、Jekyll ブログを Quarkus Roq に移行する方法と理由を学びましょう。Markus Eisele による「Modern Java Meets Native Power: Image Processing with the FFM API in Quarkus」を読んで、Java 25 が ImageMagick とどのように統合され、高速で安全な、JNI を使用しないネイティブワークフローを実現するかを見てみましょう。設定プロパティーに基づいて Quarkus アプリケーション内のすべてのエンドポイントを無効にする簡単な方法が必要ですか？Damir Arh の投稿「Disable Quarkus endpoints with a request filter」をチェックして、素晴らしい指示を得ましょう。

また、最新の Quarkus Insights エピソード、注目のツイート/ディスカッション、および今後の Quarkus 参加イベントもご覧いただけます。

ニュースレター #64: 1月をチェックしてください！

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

より高速なビルドに向けて

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

Quarkusを最初にリリースしたとき、業界はマイクロサービスに大きく焦点を当てており、それが私たちの主なターゲットでした。しかし、Quarkusは、既存のアプリケーションをよりモダンなランタイムに移行する場合でも、新しいアプリケーションをゼロから構築する場合でも、大規模なモノリスにも完全に適しています。

Quarkusは常に大規模なアプリケーションを処理できましたが、特にビルド時間に関しては、この分野で最近大幅な改善を行いました。この記事では、これらの改善点の一部を詳しく説明します。

物語の始まり

昔々、私は大規模なモノリスを構築するためのSpring BootとQuarkusを比較した記事（フランス語で書かれているため、フランス語を話さない方には申し訳ありませんが、結果はほぼ自明です）に出会いました。

その記事では、同じ機能を実装するSpring BootアプリケーションとQuarkusアプリケーションを比較し、両方のアプリケーションを作成するためのジェネレーターも含まれていました。生成されるアプリケーションはシンプルで、いくつかのエンティティ、RESTサービス、典型的なCRUDエンドポイントを備えています。非常に興味深かったのは、エンティティとサービスの数を簡単にスケールアップして、両方のフレームワークがより大規模なアプリケーションをどのように処理するかを確認できたことです。

この種のフィードバックは本当に貴重です。改善すべき領域を特定するのに役立つだけでなく、それらを探求するための再現可能な方法も提供してくれるからです。

予想どおり、Quarkusはメモリー消費と起動時間で優れていました。しかし、ビルド時間はSpring Bootよりも著しく高かったです。これもまた驚くことではありませんでした。結局のところ、Quarkusはより多くの作業をビルド時に移行します。しかし、その差はそれでも詳しく調べるに値するほど大きかったのです。

手短に言えば、私たちは調査し、大幅に改善しました。

謝辞

まず、元の記事の著者であるSpaceFox氏に、執筆とこのような有用なジェネレーターを提供していただいたことに対し、感謝いたします。

Quarkusの世界ではよくあることですが、この道のりにおいて私は一人ではありませんでした。したがって、コード、議論、レビュー、洞察、フィードバックを通じて貢献してくださったすべての方々に感謝したいと思います。アルファベット順に、Tamás Cservenák、Sanne Grinovero、Martin Kouba、David Lloyd、Alexey Loubyansky、Matej Novotny、Yoann Rodière、Ladislav Thon (もし漏れがありましたら、お知らせください！) に感謝します。

これは主要なQuarkusの作業を対象としていますが、後述するように、 SmallRye OpenAPIプロジェクトにもいくつかの改善が加えられました。これらの貢献に対して、Mike Edgar氏とMartin Panzer氏に感謝いたします。

より高速なビルドへの道のり

この種の道のりには、当然ながらプロファイリングやフレームグラフを見つめる作業がつきものです。ホットスポットを見つけるだけでなく、自分の変更が実際に状況を改善するのか (願わくば正しい方向に！) 評価することも重要です。Javaの世界では、 Async Profiler のような強力なツールをそばに持つ幸運に恵まれてきました。

他の最適化の取り組みと同様に、賢明に戦いを選択し、避けられないトレードオフを慎重に検討することが鍵となります。

コード最適化

ビルドプロセスの様々な部分を最適化するために多大な努力が注がれました。メモリー割り当ての削減、アルゴリズムとデータ構造の最適化がその大きな部分を占めていました。

この作業により、Quarkus、Jandex、さらにはByteBuddyにわたる多数のプルリクエストが生まれました。

並列化

私たちのビルドプロセスは既に大規模に並列化されていますが、Hibernate ORMプロキシの生成など、並列化されていなかったいくつかの領域を特定しました。私たちはそれを修正しました。

もう一つの改善点は、大規模なJARアーカイブの作成でした。これは、大量のリソースを読み取り、圧縮することを含むため、本質的に低速であり、I/OとCPUの両方を大量に消費します。これまで、私たちはZipFileSystemを使用して、シングルスレッドでリソースを一つずつ追加しながらJARを構築していました。それ以来、Commons Compressが提供する並列圧縮サポートを使用するように切り替えました。

この変更には、JARアセンブリコードのかなりの大規模なリファクタリングが必要でしたが、それだけの価値は十分にありました。

無駄をなくす

他のすべての最適化はGradleビルドにも同様にメリットをもたらしますが、以下の変更はMavenのデフォルトライフサイクルに関連するため、Mavenに固有のものです。

これらすべての最適化により、quarkus-maven-plugin の様々なゴールに費やされる時間は、参照バージョン3.25.1と比較して半分に短縮されました。 これは素晴らしいことですが、サンプルアプリケーションのビルドには依然として約2分かかり、これは望ましい時間よりも長いです。

一歩引いて、全体像を見る時が来ました。

Quarkusアプリケーションの場合、主に次の2つの理由で独自のJARを構築します。

追加のリソースとメタデータを含める必要があります。
起動時間を改善するために設計されたカスタムJARパッケージを導入しました。

これは、Commons Compressが提供する並列圧縮サポートを活用することで最適化したプロセスです。

しかし、Mavenを使用する場合、Quarkusアプリケーションは依然として従来の jar Mavenプロジェクトです。これは jar パッケージングの標準ライフサイクルに従うため、Mavenは maven-jar-plugin を使用して従来のJARもビルドします。

一歩引いて考えると、実際にはこのJARは99%のケースで必要ありません。したがって、構築を避けるべきです（ただし、絶対に必要な場合はその柔軟性を維持します）。

Quarkus 3.31では、独自のライフサイクルを持つ quarkus パッケージングを導入しました。このパッケージングは、Quarkusアプリケーションモジュール自体にのみ使用されることを意図しています。これにより、quarkus-maven-plugin のゴールが自動的にバインドされ、pom.xml のボイラープレートが減り（新しいゴールが追加されても変更は不要）、さらに重要なことに、maven-jar-plugin の実行も maven-install-plugin もバインドされません。これにより、大規模なアプリケーションのビルドが大幅に高速化され、すべてのアプリケーションに全体的なメリットをもたらします。

新しく生成されるアプリケーションでは、この新しい quarkus パッケージングがデフォルトになります。

3.31がリリースされたら、既存のアプリケーションを新しいパッケージングに切り替えるために、以下の変更を適用することもできます。

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	デフォルトの `jar` パッケージングの代わりに `quarkus` パッケージングを使用します。
2	これは重要であり、生成されたプロジェクトにはかなり前から存在しています。まだ存在しない場合は追加してください。
3	ゴールは削除してください。これらは自動的に処理されるため、二重に実行する必要はありません。

その影響のアイデアを示すと、私たちのサンプル大規模アプリケーションでは、この変更だけでビルド時間が2分から37秒に短縮されました。

その後の展開

SmallRye OpenAPI

2025年11月、私は最初のQuarkusコミュニティコールでこの作業の一部を発表しました（コミュニティコールの詳細についてはこちらを参照してください）。

このプレゼンテーションに続いて、私たちの常連コミュニティ貢献者の一人であるMartin Panzer氏が、大規模アプリケーションのビルドがいかに遅くなるかを示す SmallRye OpenAPIプロジェクトの課題を提起しました。彼は堅牢な再現手順を提供し、これによりMike Edgar氏が、SmallRye OpenAPIが全体のビルド時間にもたらす貢献を大幅に削減するいくつかの改善を実装することができました。

これらの変更はQuarkusのビルド時間に直接的な利益をもたらしますが、SmallRye OpenAPIは他のランタイムでも使用されているため、より広範なJavaエコシステムにも良い影響を与えるでしょう。

要点はシンプルです。何かおかしいことに気づいたら報告してください。私たちはそれを改善できるかもしれません。

悪名高き ClassTooLargeException

Quarkusでは、かなりの量のバイトコードを生成します。大規模なアプリケーションでは注意が必要で、規模が大きくなると、生成されたバイトコードが特定の制限（例えば、メソッドサイズやクラスサイズの制限）に達する可能性があります。

元のフランス語の記事では、特定の規模でこのような制限に達したことが述べられていました。公平に言えば、その規模はすでにかなり大きいものでしたが、あるクラスがたまたま限界を超えたというだけで、任意の制限に遭遇するのは理想的ではありません。

私たちは最近この制限を緩和し、Quarkusはより大規模なアプリケーションを扱えるようになりました。この改善もQuarkus 3.31で利用可能になります。

Java 25

最近、私たちはバイトコード生成のほとんどを、Class-File API を基盤とする Gizmo 2 を使用するように書き換えました。この作業はまだ進行中ですが、当社の CDI 実装である ArC などの主要コンポーネントはすでにこれに依存しています。

Java 17 と 21 との互換性を維持するため、現在は Class-File API のバックポートを使用していますが、Class-File API は基盤となる JDK の一部のクラスに依存しています。これらのクラスのいくつかは Java 25 で大幅な最適化が施されており、その結果、Java 25 で実行するとバイトコード生成のパフォーマンスが著しく向上します。

Quarkus 3.31 は Java 25 の完全なサポートを提供する予定であるため、これらのパフォーマンス向上を活用し、アプリケーションのビルドにこれを使用することをお勧めします。

まとめ

Quarkus は常に開発者エクスペリエンスの限界を押し広げてきました。私たちは開発モードを導入し、Dev Services のコンセプトを開拓するなど、多くのことを実現してきました。

しかし、開発者エクスペリエンスを向上させることは、時には基本に立ち返ることを意味します。つまり、ビルド時間です。

まさにそこに私たちは注力しました。Quarkus アプリケーションをより速く（そしてより環境に優しく！）ビルドすることを楽しんでいただければ幸いです。

もしビルドプロセスの改善にさらなる機会を見つけられた場合は、遠慮なく課題をオープンしてください。私たちは常に新しいアイデアを歓迎しています。

参加のお誘い

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

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

Quarkus 3.30.6 - メンテナンスリリース

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

本日、Quarkus 3.30 ストリームの新しいメンテナンスリリースである Quarkus 3.30.6 をリリースしました。これは、2026 年最初のリリースとなります。

Quarkus 3.31 は今月末にリリースされる予定です。

Update

Quarkus 3.30 にアップデートするには、Quarkus CLI の最新バージョンにアップデートし、以下を実行することをお勧めします。

quarkus update

quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.30 にアプリケーションを更新できることに注意してください。

アプリケーションに必要な調整の詳細については、 Quarkus 3.30 マイグレーションガイドを参照してください。

完全な変更履歴

3.30.6 の完全な変更履歴は GitHub で確認できます。

参加のお誘い

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

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

Dev Services のより優れた作成方法

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

Quarkus 3.25 では、 Dev Services を作成するための新しい API が導入されました。この新しいモデルは、すべてのテストのためのすべての Dev Services が JUnit のディスカバリーフェーズで開始され、ポートの競合、設定の混信、および過剰なリソース消費を引き起こす可能性があるという問題を修正します。この問題は、Quarkus 3.22 におけるテストクラスローディングの書き換えの副作用でした。リソース消費の削減に加え、この API がエクステンション開発者にとって Dev Services の作成をよりシンプルにし、ディスカバリーの管理やコンテナーの再利用といった重い処理の一部を Quarkus コアに移行させることも期待しています。

ユーザーにとっての変更点

ユーザー側で必要なアクションはありません。

複数のプロファイルやテストリソースを使用するテストスイートがある場合、重複するコンテナーが同時にアクティブになることはなくなります。コンテナーは順番に起動するようになります。

ただし、これは各エクステンションを新しいモデルに変換する必要があるため、エクステンションに依存します。これまでに Redis、Lambda、Narayana、Kafka のエクステンションが変換されました。変換の進捗状況は、 #45785 のサブイシューで確認できます。回避策として、依存しているエクステンションがまだ変換されていない場合は、競合するテストを別々のプロジェクトに分割することで症状が解消されるはずです。

いつものように、問題や奇妙な点に気づいた場合は、 zulip で知らせるか、イシューを起票してください。

背景

旧 API を使用するすべての Dev Services は、(Quarkus 3.22 以降) JUnit のディスカバリーフェーズで開始されます。これは、それらがバイトコード操作や他のアプリケーション初期化ステップとともに、オーグメンテーションフェーズ中に開始されるためです。テストの設計が変更された際、すべてのオーグメンテーションはテスト実行の開始時、つまり JUnit のディスカバリーフェーズ中に行われるようになりました。これは、すべての Dev Services もテスト実行の開始時に開始されることを意味します。異なる Dev Services 設定を持つ複数のテストクラスがテスト実行前にオーグメンテーションされると、設定の異なる複数の Dev Services が同時に実行される可能性があります。

新しいモデルでは、Dev Services はオーグメンテーションの後、アプリケーションの実際の起動の前に開始されます。

エクステンション所有者にとっての変更点

新しい Dev Services モデルは古いモデルとの後方互換性を維持しているため、エクステンション所有者が何かを行う必要はありません。実際、新しいモデルの最初の数リリースでは、API が安定するまでエクステンション所有者は何もしないことを推奨していました。

現在は、より簡潔なプログラミングモデルとリソース使用量の削減という利点を享受するために、エクステンションの移行を開始するのに良い時期です。これにより、古いモデルによって引き起こされるいくつかの非推奨警告も解決されます。新しい API に移行したエクステンションは、古いバージョンの Quarkus では動作しなくなることに注意してください。3.25 が可能な最小バージョンとなりますが、最小バージョンとして 3.27 または 3.28 を設定することをお勧めします (詳細は後述)。

新設計の原則

Dev Services はビルド時に準備されますが、実際の start() 呼び出しはビルド後、ランタイム前に行われます。
エクステンションプロセッサーで静的変数を使用しないこと。
Dev Service の作成はビルダーによって処理されます (外部管理インスタンスへの接続と新しいサービスの作成には、それぞれ異なるビルダーがあります)。
サービスの開始後にのみ判明する設定は、 configProvider() を使用して渡すことができます。

移行チェックリスト

エクステンションのビルドファイルを更新し、 quarkus-devservices ランタイムモジュールと quarkus-devservices-deployment モジュールの両方に依存するようにします (ただし、これによる影響については Quarkus バージョンの選択に関する議論を参照してください)。
新しいサービスの開始と停止のメソッドを持つ io.quarkus.deployment.builditem.Startable の実装を提供します。コンテナーベースのサービスの場合、 GenericContainer を継承して Startable を実装するのが良いパターンです。
DevServicesResultBuildItem を直接構築する代わりに、 DevServicesResultBuildItem 上の discovered() および owned() ビルダーを使用するように切り替えます。
- ビルダーのすべてのメソッドを呼び出す必要はありませんが、所有(owned)サービスの場合は startable() 、 serviceName() 、 configProvider() 、および serviceConfig() がほぼ常に必要になります。
アンチパターンのコードチェック。
- エクステンションのコードで Dev Service を停止または開始してはいけません。
- シャットダウンリスナーを削除します。クリーンアップはサービスの Startable の stop() メソッドで処理する必要があります。
- 新しいモデルでは RunningDevService 型を使用してはいけません。
- エクステンションプロセッサー内の静的変数 (サービスインスタンスへのポインターなど) を削除します。
- システムプロパティーやその他のオーバーライドを使用して、新しいサービスにアクセスするための設定を直接設定しようとしないでください。代わりに configProvider() を使用してください。

移行の詳細

エクステンションプロセッサーの静的フィールドの排除

エクステンション開発者は、インスタンス間の通信を静的変数に依存すべきではありません。プロセッサーの呼び出し順序がアプリケーションの実行順序と同じになると想定してはいけません。

エクステンション作成ガイドには、「ビルドステップ間の状態の受け渡しは、たとえステップが同じクラス内にあっても、ビルドアイテムを介してのみ行うべきである」と記載されています。しかし、ほぼすべての Dev Service 実装がこのルールを破り、以前に作成されたサービスを追跡するために静的フィールドを使用していました。

新しいモデルに移行する際の優れたヒューリスティックは、すべての静的フィールドをなくすことです。たとえば、次のようなフィールドをすべて削除します。

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

サービスの再利用か交換かの判断は、設定の差分に基づいて一元的に処理されるようになりました。

シャットダウンロジックの排除

サービスのライフサイクルが一元的に管理されるため、シャットダウンリスナーやサービスを停止するためのその他のロジックも削除する必要があります。

`RunningDevService` への参照の削除

プロセッサーはサービスの開始を処理しないため、 RunningDevService を返してはいけません。

ビルダーの使用

直接構築する代わりに、新しいビルダー API を使用してください。作成されるサービスには owned() を、検出された外部管理サービスを登録するには discovered() を選択します。

例:

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

再利用の適格性

一元化されたライフサイクル管理は、サービスが再利用可能かどうかをどのように判断するのでしょうか。これは、比較の基準として使用するためにビルダーに渡される「同一性キー」(設定オブジェクト) に基づいています。

主要なメソッドは .serviceConfig(myConfig) です。現在の設定は、再起動ごとに実行中のサービスの設定とリフレクションによって比較されます。

`Startable` の役割

遅延開始をサポートするために、 Startable の実装をビルダーに渡します。 (言うまでもないことですが、 Startable で start() を 呼び出さないで ください。 Quarkus インフラストラクチャーが適切なタイミングでサービスを開始します。) (言うまでもないことですが、 Startable で start() を 呼び出さないで ください。 Quarkus インフラストラクチャーが適切なタイミングでサービスを開始します。)

コンテナーベースのサービスの場合、通常は GenericContainer を継承するのが便利です。その場合、 start() を実装する必要さえありません。ほとんどの Dev Services 実装はすでに GenericContainer のサブクラスを提供しているため、差分は implements Startable を追加し、 close() メソッドを追加するだけです。 close メソッドはスーパークラスに委譲できます。

例:

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();
        }

依存関係の変更と最小 Quarkus バージョンの設定

この部分は残念ながら少し厄介です。 Quarkus 3.28 では、新しい devservices ランタイムモジュールが導入されました。ほとんどのエクステンションにはデプロイメントモジュールとランタイムモジュールの両方がありますが、歴史的に Dev Services にはデプロイメントモジュールしかありませんでした。関連するランタイムクラスは他のモジュールに存在していました。ランタイムモジュールは 3.28 で追加されました。破壊的な変更になる可能性があるため、LTS 後に行われました。それは良いアイデアのように思われましたが、予期せぬ結果をもたらしました。新しいモジュールの導入は後方互換性を維持する方法で行われましたが、前方互換性は維持されませんでした。つまり、3.27 に対してビルドされたエクステンションは 3.27 LTS で動作しますが、3.28 以降のバージョンでは動作しません。3.28 でビルドされたエクステンションは 3.27、および 3.28 以降のバージョンで動作します。

このため、エクステンションの 3.27 用と 3.28+ 用のブランチを作成するか、単に 3.28 に対してビルドする必要があります。 3.28 に対してビルドする場合は、Quarkus ツールがそのエクステンションを 3.27 と互換性があると認識できるように、エクステンションのメタデータで最小 Quarkus バージョンを手動で設定する必要があります。

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

3.28 に対してビルドすることを選択した場合は、ランタイムモジュールの pom.xml に以下を追加してください。

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

FAQ

Dev Service の開始後にビルドステップで何かを実行するにはどうすればよいですか。

Dev Service がビルドフェーズで開始されることはないため、これは不可能です。ただし、ビルダーの postStartHook を使用すると、Dev Service が開始された後にアクションを実行できます。アプリケーションに設定を渡すには、レコーダーを使用できます。

一般的に、Quarkus の哲学は作業をアプリケーションの開始時からビルド時に移行することであり、その逆ではありません。作業を postStartHook やレコーダーに移動する必要がある場合は、パフォーマンスへの悪影響を避けるために、移動する量を最小限に抑えるようにしてください。多くの場合、コードは Dev Service が作成されることを知る必要がありますが、実際のアドレスを知る必要はありません。これは、マーカービルドアイテムを使用した通常のビルドフローの一部として処理し、フックの一部として実行するものを最小限に抑えることができます。

Dev UI でサービスへのリンクを公開するにはどうすればよいですか。

サービスに管理コンソールがある場合、Dev UI でそのリンクを公開するのは良いパターンです。旧 Dev Services モデルでは、次のようなコードでエクステンションのカードをカスタマイズしていたかもしれません。

   @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;
   }

URL はビルド時には不明であるため、これは機能しなくなります。代わりに、 url メソッドを dynamicUrlJsonRPCMethodName に置き換え、 RPC メソッド名を渡します。

     .dynamicUrlJsonRPCMethodName("getMyUrl")

3.32 からは、メソッド呼び出しでパラメーターを渡すこともできます。たとえば、次のようになります。

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

提供クラスを登録するためのビルドステップを追加します。

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

エクステンションのランタイムモジュールで、 getMyUrl メソッドを持つ MyJsonRPCService クラスを作成します。

例

差分を見ると、何をすべきかがわかりやすい場合があります。

コンテナーベースではない Dev Service を使用した例については、 Lambda の変換を参照してください。 compose を使用し、既存の外部コンテナーを再利用し、開始後の設定を行う、より複雑な変換については、 Kafka の変換の KafkaDevServicesProcessor 部分のみを参照してください。

Dev Services ライフサイクルのワーキンググループは現在も進行中であり、貢献を歓迎しています。

Quarkus 3.30.5 - Maintenance release

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

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

See you all next year!

Update

Quarkus 3.30 に更新するには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.30 へとアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.30 移行ガイドを参照してください。

完全な変更履歴

You can get the full changelog of 3.30.5 on GitHub.

参加のお誘い

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

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

Quarkus Hibernate with Panache Next

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

Introducing a new version of Panache

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

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

Please report feedback either on Zulip or via GitHub issues.

What was wrong with the old Panache APIs?

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

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

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

So, what’s this new API?

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

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

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

    public enum Breed {
        CUTE, HAIRLESS;
    }

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

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

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

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

Here’s what you can notice right away:

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

You could use it like this:

    @Inject
    Cat.Repo repo;

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

        // Persist the cat
        cat.persist();

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

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

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

        // Delete our cat
        cat.delete();

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

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

Here’s where it gets better

Want a reactive version of your entity for stateless sessions?

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

    public enum Breed {
        CUTE, HAIRLESS;
    }

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

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

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

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

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

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

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

Here’s where it gets really better

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

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

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.

Update

Quarkus 3.30 に更新するには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.30 へとアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.30 移行ガイドを参照してください。

完全な変更履歴

You can get the full changelog of 3.30.4 on GitHub.

参加のお誘い

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

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

Quarkus feature flags

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

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

More specifically, it provides:

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

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

Flag

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

Simple example

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

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

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

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

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

package org.example;

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

@ApplicanScoped
public class MyService {

    @Inject
    Flags flags;

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

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

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

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

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

Flag providers

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

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

@ApplicationScoped
public class MyInitService {

   AtomicBoolean alpha = new AtomicBoolean();

   @Inject
   InMemoryFlagProvider provider; (1)

   @Startup (2)
   void addFlags() {
      provider.addFlag(Flag.builder("my-feature-alpha") (3)
            .setCompute(ctx -> BooleanValue.from(alpha.get())) (4)
            .build());
   }
}

1	Inject `InMemoryFlagProvider` to add/remove flags.
2	This method is automatically executed at application startup.
3	The `InMemoryFlagProvider` has higher priority and overrides the flag provided in config.
4	The current value of `my-feature-alpha` is calculated from `MyInitService#alpha`.

This way we can control the current value of my-feature-alpha easily. However, in real use cases we will probably need to persist the feature flags in an external system.

The quarkus-flags-hibernate-orm extension provides integration with Hibernate ORM. It discovers all JPA entities annotated with @io.quarkiverse.flags.hibernate.common.FlagDefinition and generates a flag provider automatically. The generated provider simply loads all flags from the database. A mapping looks like:

import jakarta.persistence.Entity;

import io.quarkiverse.flags.hibernate.common.FlagDefinition;
import io.quarkiverse.flags.hibernate.common.FlagFeature;
import io.quarkiverse.flags.hibernate.common.FlagValue;
import io.quarkus.hibernate.orm.panache.PanacheEntity;

@FlagDefinition (1)
@Entity
public class MyFlag extends PanacheEntity {

    @FlagFeature (2)
    public String feature;

    @FlagValue (3)
    public String value;

}

1	Marks a flag definition entity.
2	Defines the feature name of a feature flag.
3	Defines the value of a feature flag.

The feature flags are collected at runtime. More specifically, the extension injects all CDI beans that implement io.quarkiverse.flags.spi.FlagProvider and calls the FlagProvider#getFlags() method. You can easily implement your own provider.

Flag evaluators

In real applications, you will very likely need some dynamic evaluation logic based on some application state, such as the current user or current time. There is the io.quarkiverse.flags.spi.FlagEvaluator SPI which makes it possible to externalize the computation of the current value of a feature flag. Flag evaluators must be CDI beans. By default, a flag can reference one FlagEvaluator in its metadata with a key evaluator. This evaluator is automatically used to compute the current value for any flag produced by means of Flag.Builder (i.e. created by Flag#builder(String)). There are also several built-in evaluators available.

Current time

The io.quarkiverse.flags.TimeSpanFlagEvaluator evaluates a flag based on the current date-time obtained from the system clock in the default time-zone. The current time must be after the start-time (exclusive) and before the end-time (exclusive).

quarkus.flags.runtime."my-feature-alpha".meta.evaluator=quarkus.time-span (1)
quarkus.flags.runtime."my-feature-alpha".meta.start-time=2001-01-01T10:15:30+01:00[Europe/Prague] (2) (3)

1	Assign the evaluator to the flag. Note that we do not specify the initial value for `my-feature-alpha` - it is `true` by default.
2	The current date-time must be after the specified `start-time`. The `java.time.format.DateTimeFormatter.ISO_ZONED_DATE_TIME` is used to parse the `start-time` value.
3	We do not specify the `end-time` metadata value, so there is no upper bound for the time inverval.

Current user

The SecurityIdentityFlagEvaluator from the quarkus-flags-security extension can be used to compute the current value of a feature flag based on the current SecurityIdentity. A typical feature flag configuration looks like:

quarkus.flags.runtime."my-feature-alpha".meta.evaluator=quarkus.security.identity (1)
quarkus.flags.runtime."my-feature-alpha".meta.authenticated=true (2)
quarkus.flags.runtime."my-feature-alpha".meta.roles-allowed=foo,bar (3)

1	Assign the evaluator to the flag. Note that we do not specify the initial value for `my-feature-alpha` - it is `true` by default.
2	The current user must be authenticated.
3	The current user must have one of the defined roles.

The UsernameRolloutFlagEvaluator, on the other hand, is an evaluator using a simple percentage-based rollout strategy, based on a consistent numerical representation of the current user name. It can be used to implement gradual rollout. A typical feature flag configuration may look like:

quarkus.flags.runtime."my-feature-alpha".meta.evaluator=quarkus.security.username-rollout (1)
quarkus.flags.runtime."my-feature-alpha".meta.rollout-percentage=20 (2)

1	Assign the evaluator to the flag. Note that we do not specify the initial value for `my-feature-alpha` - it is `true` by default.
2	Enable the flag for the given percentage of users.

CRON

The quarkus-flags-cron extension provides the CronFlagEvaluator that can be used to compute the current value of a feature flag based on the current date-time obtained from the system clock in the default time-zone and the configured CRON expression. A typical feature flag configuration may look like:

quarkus.flags.runtime."my-feature-alpha".meta.evaluator=quarkus.cron (1)
quarkus.flags.runtime."my-feature-alpha".meta.authenticated=* * * * mon (2)

1	Assign the evaluator to the flag. Note that we do not specify the initial value for `my-feature-alpha` - it is `true` by default.
2	The current date-time must match the given CRON expression. In this particular case, the flag will be enabled every Monday.

By default, the Unix/crontab syntax is used. However, it is also possible to use the syntax from Cron4j, Quartz and Spring. For more information, see the documentation.

The case for multiple evaluators

Sometimes it might be useful to combine several evaluators to compute the value of a flag. The core extension provides io.quarkiverse.flags.CompositeFlagEvaluator that evaluates a flag with the specified sub-evaluators.

quarkus.flags.runtime."my-feature-alpha".meta.evaluator=quarkus.composite (1)
quarkus.flags.runtime."my-feature-alpha".meta.sub-evaluators=quarkus.time-span, quarkus.security.identity (2)
quarkus.flags.runtime."my-feature-alpha".meta.start-time=2026-01-01T12:00:00+01:00[Europe/Prague] (3)
quarkus.flags.runtime."my-feature-alpha".meta.roles-allowed=admin (4)

1	Assign the evaluator to the flag. Note that we do not specify the initial value for `my-feature-alpha` - it is `true` by default.
2	The value of `sub-evaluators` represents a comma-separated list of sub-evaluator identifiers. They are executed in the specified order. In this particular case, the `TimeSpanFlagEvaluator` is executed first and then the `SecurityIdentityFlagEvaluator`.
3	The current date-time must be after the specified start-time.
4	The current user must have the role `admin`.

Extensibility

Flag providers and flag evaluators are CDI beans. So all you have to do is add a bean that implements FlagProvider or FlagEvaluator in your application. You can use CDI interceptors and even decorate these components.

まとめ

Quarkus Feature Flags is a lightweight and extensible extension that can help you build more flexible applications. Feedback, feature requests and contributions are welcome. Feel free to create questions and issues on GitHub repository: https://github.com/quarkiverse/quarkus-flags/issues.

Quarkus Newsletter #63 - December

James Cobb (https://twitter.com/insectengine) — Thu, 11 Dec 2025 00:00:00 +0000

Check out "Java Meets the Future: How Quarkus Seamlessly Combines Architecture, Performance, and Cloud-Native" by Holger Tiemeyer to see how Quarkus impressively demonstrates that even an aging ecosystem like Java can always be reinvented to meet the demands of the next technological era. Learn how to build Quarkus application images using Cloud Native Buildpacks and OpenShift Builds with Piotr Minkowski’s article; "Quarkus with Buildpacks and OpenShift Builds". Learn how to generate, extend, and optimize a Quarkus actuator-style endpoint with build-time processing, runtime beans, and native support by reading "How to Build a Custom Quarkus Actuator Extension: A Complete Java Developer’s Guide" by Markus Eisele. Did you know about Roq? A powerful new tool that combines Java and Quarkus. Ok, prep a warm drink and put on some soft music and let’s find out why Roq is so cool with the comfort of Quarkus Dev Mode and all its eco-system. Bonus: a touch of TailwindCss to make it look great! Learn more by reading Andy Damevin’s article "Discover Roq, the Quarkus Way for Static Site Generation in Java".

最新のQuarkus Insightsエピソード、トップツイート/ディスカッション、今後開催されるQuarkus参加イベントもご覧いただけます。

Check out Newsletter #63: December!

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

Quarkus 3.30.3 - Maintenance release

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

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

Update

Quarkus 3.30 に更新するには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.30 へとアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.30 移行ガイドを参照してください。

完全な変更履歴

You can get the full changelog of 3.30.3 on GitHub.

参加のお誘い

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

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

Quarkus 3.30.2 - Maintenance release

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

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

Update

Quarkus 3.30 に更新するには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.30 へとアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.30 移行ガイドを参照してください。

完全な変更履歴

You can get the full changelog of 3.30.2 on GitHub.

参加のお誘い

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

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

Quarkus: A Runtime and Framework for Cloud-Native Java

Michal Mickey Maléř (https://twitter.com/mickeymaler) — Thu, 27 Nov 2025 00:00:00 +0000

Public clouds such as AWS, Microsoft Azure, and Google Cloud, and platforms like Red Hat OpenShift, favor services that start fast and stay lean. Quarkus is engineered for exactly that. Build time processing reduces runtime overhead and results in rapid startup, a small memory footprint, and frictionless deployment across Kubernetes, OpenShift, serverless, and managed container services in any cloud. If your Java services need to start in milliseconds, run dense on shared nodes, and still feel great to build, Quarkus was made for that job.

Quarkus is a Java runtime that seamlessly integrates popular frameworks and libraries, shaping both the structure of modern applications and the developer experience behind them. In this post, “runtime” means the full execution stack in production: JVM or native, plus Quarkus and the integrated frameworks.

Quarkus itself can also work as a framework, as it constitutes a higher-level layer that provides structure and APIs.

Why Quarkus stands out?

In modern software development, runtimes and frameworks form the foundation of productivity and consistency. Frameworks promote uniformity, simplify infrastructure, and enable automation at scale.

Quarkus is a cloud-native Java runtime that integrates multiple frameworks and optimizes them for fast startup, low memory use, and smooth deployment across any cloud. It runs well on Kubernetes and Red Hat OpenShift, and it also integrates with native cloud services, from compute platforms such as AWS EC2 and Google Cloud Run to serverless offerings and managed container platforms.

Then, during development, Quarkus live reload provides instant feedback by applying code changes without a rebuild or restart. This shortens the inner loop and helps teams iterate faster than traditional redeploy cycles.

But beyond speed and live reload, Quarkus integrates established Java specifications such as CDI-Lite, JAX-RS, and JPA, with implementations provided by Arc (CDI-Lite), RESTEasy (JAX-RS), and Hibernate ORM (JPA). It also enforces its own conventions, drives behavior with annotations, and defines how applications are structured.

In this sense, Quarkus is a development framework and runtime for cloud-native Java applications. It adheres to industry standards and offers compatibility with technologies such as Spring, Apache Kafka, and Apache Camel to support familiar, flexible development models.

Quarkus as a versatile framework

Beyond staple traits of modern frameworks, Quarkus introduces two platform-defining features: buildtime optimization and deep extensibility.

Buildtime optimization: Quarkus shifts work from runtime to build time wherever possible. This approach reduces startup overhead and memory usage, resulting in a lean, fast, and efficient application tailored for production.

Figure 1. Quarkus performs at build time what traditional frameworks do at runtime: reading configuration files, scanning annotations, and building a model of the application.

Figure 2. Thanks to buildtime initialization, the resulting application starts faster and consumes less memory.

Figure 3. All the benefits of buildtime initialization also apply when compiling to a native binary.
Extensibility: Quarkus exposes extension points for everything from startup hooks to request filters. Over 800 extensions allow seamless integration with modern technologies such as Kafka, OpenTelemetry, and OpenID Connect.

These extensions integrate with Quarkus and participate in its buildtime and runtime lifecycle, making them first-class components of Quarkus.

Simplified developer experience

Frameworks succeed when they reduce complexity without sacrificing flexibility. Quarkus does exactly that:

Preconfigures popular libraries with sensible defaults.
Offers unified configuration and developer tooling.
Provides instant feedback with live reload and continuous testing.
Dev Services for automatic provisioning of databases, brokers, and other services in dev mode.
Continuous testing to run tests in the background and surface results immediately.

This makes Quarkus both powerful and approachable.

You can start with a simple REST endpoint and scale it into a production-grade service without changing your development model.

Figure 4. Frictionless developer experience: Vastly improved development feedback loop, unified approach to producing different package types, and using proven APIs that Java developers already know.

These features give developers structure, sensible defaults, and clear conventions during development, and they deliver fast startup, low memory use, and operational consistency in production.

Performance that matters

Teams optimize for different goals, such as startup latency, sustained throughput, memory footprint, elasticity, and cost. Quarkus addresses these needs by shifting work from run time to build time, keeping one development model across JVM and native, and exposing production signals such as health checks, metrics, and tracing.

Start with JVM mode for most services. On the JVM, Quarkus often starts faster and uses less memory than traditional JVM-based runtimes because it performs more work at build time. Just-in-time compilation raises steady-state throughput, scales well across cores, and offers mature garbage collectors and tuning options. The JVM also provides rich observability and diagnostics, which help you understand and tune live systems.

Use native mode when startup latency and memory footprint are strict constraints. Native executables start in milliseconds and can use less memory, which supports scale-to-zero workflows and lowers idle costs on small instances. Trade-offs include lower peak throughput, limited multi-core scaling, a single-threaded garbage collector in current native images, longer build times, and a slower inner loop for developers.

If your system needs both profiles, split by workload. Run bursty or event-driven endpoints in native mode, and run long-lived high-throughput services on the JVM.

Observability note. JVM mode exposes richer diagnostics and metrics, including GC, heap, and thread telemetry, JFR, and profiler support, which makes issue triage and performance tuning easier. Native mode still exports application-level metrics and traces with Micrometer and OpenTelemetry, but it offers fewer VM-level signals.

Always measure your workload:

For native, reduce reflection and dynamic class loading, trim resources, and consider profile-guided optimizations (PGO) where supported. PGO is not available in Mandrel and currently requires an Oracle GraalVM distribution that provides PGO.
For the JVM, choose a garbage collector that matches your latency and heap goals, budget for warmup, and test steady-state throughput under realistic load.

Taken together, these in production choices provide measurable wins:

セキュリティー

Quarkus uses a standards-first composable security model. You enable what you need and configure it for your environment:

Transport: Enable HTTPS in the application by configuring TLS.
Authentication: Choose Basic, form-based, mTLS, OpenID Connect (OIDC), or WebAuthN.
Authorization: Enforce RBAC on web endpoints with @RolesAllowed, @DenyAll, and @PermitAll.

This lets you apply the right security controls for each deployment.

Observability and control surfaces

Common control surfaces, such as metrics, logging, tracing, and configuration, are essential for site reliability engineers (SREs) and platform teams.

Quarkus exposes:

Unified logging with quarkus-logging.
Centralized logging with OpenTelemetry (OTLP logs) with OpenTelemetry.
Metrics and tracing with Micrometer and OpenTelemetry.
Unified configuration of all the application’s aspects by using application.properties or environment variables.

This standardization enables automation and scalable monitoring.

Modular and production-ready

Following a lean-core, modular-at-the-edge approach, Quarkus delivers:

A minimal core for fast startup.
Pluggable extensions for authentication, tracing, messaging, and more.
Built-in production primitives, including health checks, readiness and liveness probes, and graceful shutdown.
Fault tolerance with standard annotations, for example, retries, circuit breakers, bulkheads, and timeouts.

Whether you are building a prototype or deploying to OpenShift, Quarkus adapts. This modularity spans both the framework-level APIs developers work with and the runtime behaviors that execute beneath them.

Because Quarkus modularity is declarative and unified across extensions, it supports a platform-like developer experience without the rigidity of traditional frameworks.

Building your stack with Quarkus

We will explore this topic in depth in part 3 of this series. For now, here is how Quarkus fits into the picture.

Frameworks can serve as a foundation for creating higher-level abstractions.

Quarkus fits this model by enabling teams to build customized stacks and internal frameworks on top of it.

Unlike many traditional frameworks, Quarkus provides a unified extension architecture that supports deep customization. Organizations can tailor Quarkus to fit specific domains, technologies, or compliance needs. This enables the creation of organization-specific developer experiences, including internal stacks built on a unified Quarkus extension architecture.

By encouraging consistency, offering buildtime integration, and exposing clean extension points, Quarkus supports the creation of opinionated, scalable internal frameworks without forking or reinventing the core.

By packaging Quarkus extensions, curated defaults, and service templates into an internal Quarkus stack, teams focus on business logic. At the same time, your framework layer standardizes infrastructure, security, and operational integrations across services. This has been proven by Logicdrop, who refactored their entire Spring Boot stack with Quarkus, reducing container size by ~75%, achieving sub-second startup times, and significantly improving developer productivity.

For more information, see the Logicdrop customer story and their GitLab automation write-up.

まとめ

Quarkus unifies the strengths of a development framework and a runtime. As a framework, it provides structure, conventions, and a cohesive developer experience. As a runtime, it delivers fast startup, low memory use, and operational consistency in the cloud. This dual role helps teams standardize practices, reduce costs, and ship resilient cloud-native services.

Quarkus is built in the open under the Apache License 2.0, governed with the Commonhaus model, and developed end-to-end on GitHub. Beyond the core project, the ecosystem includes the Quarkiverse Hub, a community-run collection of Quarkus extensions and related projects. The Quarkiverse Hub provides repository hosting with build, CI, and release publishing, so features land as versioned, testable modules you can adopt, fork, or extend.

So, that’s all for now, thank you for reading, and let’s meet again in the third article of this series, which will cover building your own stack with Quarkus.

For a closer look at how Quarkus makes Java cloud-native, see the introductory blog post.

Quarkus 3.30 - JsonView on REST Client, Hibernate Validator 9.1, CLI decrypt command, and more

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

Today, we released Quarkus 3.30.

Quarkus 3.30 introduces the following notable changes:

#51043 - Introduce support for @JsonView on the REST Client
#50196 - Update to Hibernate Validator 9.1
#50332 - Add a CLI command to decrypt secrets
#50723 - OIDC token propagation - allow users to select REST Client methods for which token should be propagated
#50806 - Support method-level @OidcClientFilter bindings
#50952 - Use @QuarkusIntegrationTest tests as a test run for AOT file generation

As usual, this release also includes many bug fixes and improvements.

Update

Quarkus 3.30 に更新するには、Quarkus CLI の最新バージョンに更新してから、以下を実行することをお勧めします。

quarkus update

なお、quarkus update は、Quarkus の任意のバージョン (2.x を含む) から Quarkus 3.30 へとアプリケーションを更新できます。

アプリケーションに必要な調整の詳細については、 Quarkus 3.30 移行ガイドを参照してください。

変更点

RESTクライアント

@JsonView support has been added to the REST Client. You can now use this annotation on your REST Client interfaces to control the serialization and deserialization of JSON data based on different views.

This feature used to be only supported on the server side.

Hibernate Validator

Hibernate Validator has been updated to version 9.1, which comes with some significant performance improvements.

コマンドラインインタフェース

A new config decrypt command has been added to the Quarkus CLI to decrypt secrets that were encrypted using the quarkus config encrypt command.

OIDC

OIDC token propagation has been enhanced to allow users to select specific REST Client methods for which the token should be propagated.

Additionally, method-level @OidcClientFilter bindings are now supported, allowing for more granular control over OIDC client behavior.

AOT cache

@QuarkusIntegrationTest tests are now used as a test run for AOT file generation.

完全な変更履歴

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

コントリビューター

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

In particular for the 3.30 release, thanks to Ales Justin, Alexey Loubyansky, Andreas Repp, Andy Damevin, Antonio Musarra, Aurea Munoz, azerr, Bruno Baptista, Christian Pieczewski, Clement Escoffier, David M. Lloyd, Eric Deandrea, eschcam, Foivos Zakkak, Fouad Almalki, Galder Zamarreño, George Gastaldi, Georgios Andrianakis, Greg Stewart, Guillaume Smet, Holly Cummins, Jakub Pietrzak, James Netherton, Jan Martiska, jcarranzan, jcjveraa, Johannes Schleger, Jonas Rutishauser, Juan Antonio Breña Moral, Julien Ponge, Junior DUSSOUILLEZ, Karm Michal Babacek, Kevin Ferrare, Ladislav Thon, Loïc Hermann, Luca Molteni, Lucas Reeh, Maciej Swiderski, Manuel Müller, Marco Belladelli, mariofusco, marko-bekhta, Martin Kouba, Matej Novotny, Matej Vašek, Matheus Cruz, Melloware, Michael Edgar, Michal Vavřík, Nicolo Pietro Belcastro, Ozan Gunalp, Peter Palaga, Phillip Krüger, Pierre Beitz, Robert Stupp, Roberto Cortez, Rolfe Dlugy-Hegwer, Rostislav Svoboda, Sanne Grinovero, Sergey Beryozkin, staillebois, Stéphane Épardaud, Teymur Babayev, Thomas Segismont, Tomas Hofman, Willem Jan Glerum, xstefank, and Yoann Rodière.

参加のお誘い

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

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

Quarkus

Introducing Quarkus Agent MCP: teaching AI agents to speak Quarkus

What is MCP?

Why a standalone server?

はじめに

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

トラブルシューティング

How auto-detection works

One flag, every JVM

Differences from Project Leyden

いくつかの数値

Container images and future work

Manual deployment today

Automated container image integration

Cache layering for Docker

謝辞

まとめ

参加のお誘い

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

変更点

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

プラットフォームの更新

完全な変更ログ

コントリビューター

参加のお誘い

A2A Java SDK 1.0.0.Beta1 Released

A2A とは？

破壊的変更

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

コントリビューター

リソース

参加のお誘い

Quarkus 3.34.6 - Maintenance release

Update

完全な変更履歴

参加のお誘い

Quarkus Newsletter #67 - April

Quarkus 3.34.5 - Maintenance release

Update

完全な変更ログ

参加のお誘い

リフレクションなしの Jackson シリアライザーをデフォルトで有効にする

リフレクションなしの Jackson シリアル化の設定

Quarkus 3.35 リリースでデフォルトで有効化

`@Transactional` for Hibernate Reactive

`DataPart.fromJson()` Factory Method