Quarkus Community Call - 2026-05-12

[cescoffier]

Hello,

On May 12th, we held our Quarkus community call focused on Modular
Quarkus - Where We Are and What's Next.

Here is a short summary. You can find the complete minutes (including
the recording) at:

• Recording: https://www.youtube.com/watch?v=IxxFmLOPhpQ
• Slides: https://drive.google.com/file/d/1Px1EyC4DaqtHNTqv5Vknztn_BPp
  G1ASC/view?usp=sharing
• Detailed Notes: Link

Recap:

David Lloyd presented the current state of modular Quarkus packaging via PR #53140, which provides experimental JLink-based modular output activated through extensions rather than configuration flags. The primary driver for JPMS adoption is the JDK's evolving security model—features like FFM (Foreign Function & Memory API) now require module-level permissions with no flat classpath alternative, and future JDK capabilities (serialization, etc.) will likely follow this pattern. The experimental PR builds a second module-based application model alongside the existing one, with enhanced module layer isolation beyond standard JDK capabilities, and has already shown measurable performance improvements in class loading speed and image size.

The team decided to merge the PR after a loose review to enable team-wide experimentation, accepting that not all extensions currently work (RESTEasy Classic confirmed broken, ~30 upstream module declaration issues identified). Guillaume emphasized that full test suite validation is impossible without modular testing infrastructure, which will require a "clean room" reboot of testing assumptions rather than transforming existing flat classpath code. Major integration work remains: container/Docker support (currently just "a line in notepad"), native image modular support (experimental branch started), and redesigned dev mode with layered class loading. Max will coordinate early engagement with the Apache Camel team, as their compatibility is critical to ecosystem success.

The migration path spans multiple releases: Quarkus 4.0 may ship experimental modular support with ~30% of extensions working (user choice between flat and modular), while Quarkus 5.0 or later would deprecate flat classpath after a coexistence period where both systems run in parallel. The team acknowledged this is a "marathon, not a sprint," with testing infrastructure, tooling ecosystem maturity, and user app compatibility as key gates before modular-by-default becomes feasible.

Also announced: emergency security releases shipped with new 4-digit versioning scheme—please update immediately if you haven't already.

---

Next call: May 26th, 2026 (topic likely Quarkus Signals)