Quarkus 3.31 & 3.32: Performance and Security Upgrades You Didn’t Notice
AOT JAR packaging, reflection-free serializers, advanced OIDC, and production-focused improvements explained.
If you build serious Java services with Quarkus, you know the visible features. Fast startup. Small memory footprint. Dev Services. Native builds. That’s the headline. I have published the first chunk of 10 (almost) hidden features end of last year. About time to refresh this with a new list.
The real improvements often hide in the release notes. Small lines in GitHub PRs. A configuration flag that removes a workaround you carried for two years. A security feature that finally closes a compliance gap.
I went through the 3.31 and 3.32 release notes and PRs so you don’t have to. Here are ten features that are not loud, but they matter in production.
You can browse the full change logs on the official Quarkus releases page.
1. Panache 2: Hibernate 7.2 Alignment and Cleaner Internals
Panache has always been one of the main reasons people stick with Quarkus. You get Active Record or Repository style, without writing boilerplate.
With 3.31 and 3.32, Panache moves forward with better alignment to Hibernate ORM 7.2 and internal cleanup that makes hot reload and lifecycle integration more predictable.
This is not just a version bump.
The team improved behavior around @Startup and lifecycle handling. That matters when you preload data, warm caches, or run migrations during boot. These are the areas that break first under load or when switching to native.
Relevant PRs:
If you are running large Panache-based codebases, upgrading means fewer edge-case surprises when combining Dev Mode, native image, and Hibernate 7.x.
And if you are a regular reader, you already know that I have blogged about this already!
2. Automatic Consul Registration
Service discovery is one of those things you don’t think about until it breaks.
Before this change, integrating with Consul often meant writing lifecycle observers to register and deregister services. That’s boilerplate. And it’s easy to forget deregistration on shutdown.
Now Quarkus can automatically register your service with Consul on startup.
One extension. One configuration. No custom event observer.
PR:
In Kubernetes-heavy environments you might rely on other discovery mechanisms. But if you run hybrid infrastructure or on-prem clusters with Consul, this saves you custom glue code and reduces operational risk.
3. Reflection-Free Jackson Serializers Enabled by Default
This one is bigger than it looks.
Jackson traditionally relies on reflection. Reflection is flexible, but it costs memory and startup time. In native mode, it also means configuration and potential runtime surprises.
Quarkus now enables reflection-free Jackson serializers by default.
Instead of discovering metadata at runtime, Quarkus generates optimized serializers at build time. That means:
Lower memory overhead
Faster serialization
Better native compatibility
Fewer reflection configuration headaches
PRs:
If you expose high-throughput REST APIs or event-driven JSON payloads, this gives you performance without changing your code.
That’s the best kind of optimization.
4. Multiple OpenAPI Documents
If you’ve ever generated OpenAPI for a large modular monolith, you know the problem. One giant document. Hundreds of endpoints. Nobody reads it.
Quarkus now supports generating multiple OpenAPI documents.
You can split documentation by packages, domains, or modules. That means:
Cleaner API boundaries
Easier external publishing
Better internal API governance
PRs:
For teams practicing internal platform engineering, this is important. You can document domain APIs separately from admin or internal endpoints.
This makes your architecture visible. And visibility reduces accidental coupling.
Also check out my OpenAPI tutorial:
Brewing Better APIs: OpenAPI and Quarkus for Java Developers
APIs are promises. They connect frontends, backends, and third-party consumers across an enterprise. But a promise written only in code is fragile: documentation drifts, expectations misalign, and integrations break.
5. aot-jar Packaging: Ahead-of-Time for JVM
Not everyone can go native. Sometimes you need the full JVM.
Quarkus introduced a new packaging type: aot-jar.
It builds on fast-jar but pushes more initialization to build time. That means faster startup and more predictable runtime behavior, even when staying on the JVM.
PRs:
This is useful in environments where:
Native is not allowed
You depend on JVM-only libraries
You want faster cold starts in containerized workloads
You don’t need to rewrite code. You change packaging. You get measurable improvements.
6. Headless AWT Support on Windows (Native Mode)
If you generate PDFs, images, charts, or QR codes, you’ve probably touched AWT indirectly.
In native mode, especially on Windows, this was fragile. Headless AWT support was incomplete, and you could hit runtime errors in production.
Recent updates improve headless AWT support on Windows native builds.
PRs:
This matters if you:
Generate invoices
Render images server-side
Use libraries that rely on
java.awtunder the hood
If you ship native executables to Windows servers, this reduces platform-specific surprises.
And this is surprisingly relevant. I have some tutorials that extensivly use AWT. One of my favorites probably is:
One Does Not Simply Build Memes with Java: Unless It’s Quarkus
What do you get when you combine a legendary Java framework with a legendary meme? A REST API that lets you generate memes on the fly with custom text. Yes, we’re going full Boromir.
7. @PermissionsAllowed on REST Data Panache
REST Data Panache is convenient. You define your entity or repository, and Quarkus generates CRUD endpoints.
But security used to require extra work. You had to secure endpoints manually or wrap generated behavior.
Now you can use @PermissionsAllowed directly on Jakarta Data repositories and REST Data Panache endpoints.
PRs:
This gives you fine-grained, declarative access control in one line.
In regulated environments, this reduces the gap between “generated convenience” and “enterprise-grade security”.
You keep developer productivity. You don’t sacrifice compliance.
8. Dev UI: Internationalization and Dynamic URLs
The Quarkus Dev UI at /q/dev is one of the underrated features of the platform.
Now it supports:
Internationalization (i18n)
Dynamic external page URLs for extensions
PRs:
Why does this matter?
If you build internal extensions or developer tooling, you can:
Localize the experience
Link dynamically to contextual dashboards or external systems
Build richer Dev UI integrations
For platform teams building custom Quarkus extensions, this is a quality-of-life improvement that makes your tooling more professional.
9. Advanced OIDC: PAR and DPoP
Security teams don’t care about startup time. They care about standards compliance.
Quarkus OIDC now includes:
Support for OAuth 2.0 Pushed Authorization Requests (PAR)
Custom DPoP nonce providers
PRs:
These features matter in high-security environments like:
Banking
Fintech
Healthcare
Government systems
PAR improves security during the authorization request phase. DPoP strengthens proof-of-possession semantics and reduces token replay risk.
If you are building serious APIs with OIDC, this closes compliance gaps without custom implementation.
10. Directory-Based TLS Trust Stores
This one solves a real DevOps pain.
In Kubernetes, certificates are often mounted as individual PEM files in a directory. Traditional Java expects a keystore.
Quarkus now allows quarkus.tls.trust-store.pem.certs to point to a directory. All PEM files inside are trusted automatically.
PR:
This means:
No manual keystore generation
No
keytoolscripting in CICleaner secret management
For teams running certificate rotation pipelines, this simplifies operations and reduces human error.
Why These “Small” Features Matter
None of these features are flashy. No new programming model. No dramatic API overhaul.
But this is how mature platforms evolve.
They:
Remove reflection by default
Improve build-time optimization
Close security gaps
Reduce boilerplate in service discovery
Simplify TLS in containerized environments
This is what enterprise Java looks like in 2026. Stable core. Fast evolution. Build-time intelligence.
If you’re on an older 3.x version, take a look at the official Quarkus releases page and scan the 3.31 and 3.32 notes yourself. The PR links above go directly to the implementation details.
Upgrading is not just about “being current”.
It’s about removing invisible technical debt you didn’t even realize you had.