Quarkus Community Call - 2026-05-26

[cescoffier]

Hello,

Yesterday, we had our Quarkus community call focused on the new Signals extension.

Here is a short summary. You can find the recording at https://www.youtube.com/watch?v=_VY9G_DMFjw
and the slide deck at https://drive.google.com/file/d/1zrh7VaQJYDxAn3mZTRIIJPpdd-1_Pcp0/view?usp=sharing.

Recap:

Martin Kouba presented Signals, a new experimental Quarkus core extension that provides type-safe, asynchronous event dispatching. The motivation: Quarkus currently has three overlapping in-box mechanisms for loosely coupled component interaction, CDI events, Vert.x event bus, and Reactive Messaging internal channels; each with significant trade-offs. CDI events are type-safe but synchronous and burdened by spec compatibility constraints; the Vert.x event bus is flexible but string-typed and lacks compile-time safety; Reactive Messaging targets pipeline processing with external brokers rather than simple in-app dispatch.

Signals takes the best of both worlds: type-safe resolution inspired by CDI (using @receives instead of @observes) and flexible emission modes borrowed from the Vert.x event bus (publish, send, request). A key design choice is that receivers are always executed asynchronously, with the execution model determined by method signature, void returns run on a worker thread, Uni or
CompletionStage returns run on the event loop, and @RunOnVirtualThread is fully supported. Signals also integrates lazily into Mutiny reactive pipelines.

A notable technical difference from CDI is how generics are resolved: Signals uses the explicit type declared at the injection point rather than the payload's runtime class, which avoids the fragile type-variable inference that CDI requires for generic events.

The discussion covered several community questions. Stéphane Épardaud proposed an alternative API in which event classes implement the Signal interface directly, eliminating the need for injection points when firing. Martin acknowledged the idea and will track it via an issue. Willem Jan Glerum reported trying to bridge Signals to Server-Sent Events and found it not straightforward with the current API; Georgios Andrianakis agreed this use case should be supported and asked Willem
Jan to open an issue with a sample application. Emmanuel Bernard and Max Rydahl Andersen helped articulate the positioning: CDI events remain preferred for synchronous and transactional use cases, while Signals becomes the recommended default for all asynchronous use cases, with virtual thread support and reactive pipeline integration as the killer features. The migration path is clean: replace Event with Signal and @observes with @receives.

The extension is available now as quarkus-signals. The team is actively collecting feedback before finalizing the API for Quarkus 4. Security identity propagation and tracing integration are identified as the main missing pieces.