Evolving Quarkus extension naming for clarity
Quarkus is about providing a modern, efficient, and productive development experience for developers leveraging the JVM. We’re committed to making it easier for you to build cloud-native applications, whether you’re using traditional blocking, reactive, or virtual thread-based programming models.
Historically, Quarkus has used the term "reactive" in the names of several extensions to indicate their additional support for non-blocking, event-driven programming.
However, we’ve found that this terminology has led to lots of confusion and misunderstanding among our users. Many users mistakenly believe that using these "reactive" extensions forces them into reactive programming, even though Quarkus, by default, recommends the traditional blocking programming model for your application and only use the reactive programming model if you have needs for it (like high concurrency requirement, or the need to orchestrate many asynchronous tasks).
With the recent production release of Virtual Threads in Java 21, the distinction between traditional, reactive, and now, virtual thread-based programming has become even more critical.
Our solution: a new naming strategy
To address this and guide our users more effectively, we’ve decided to revise the naming convention for certain extensions. This change aims to clarify the capabilities and flexibility of these Quarkus extensions, making it easier for you to choose the right extension for your project.
It will take effect with the release of Quarkus 3.9.
Here’s a summary of the changes:
-
Quarkus RESTEasy Reactive becomes Quarkus REST, emphasizing its general-purpose applicability beyond just reactive programming.
-
Quarkus SmallRye Reactive Messaging is now Quarkus Messaging, indicating its broader use cases.
-
Extensions that inherently push for a reactive programming model, like Quarkus Hibernate Reactive, will retain the "reactive" terminology.
-
Quarkus REST Client Reactive is simplified to Quarkus REST Client, unifying the naming under a more general "REST" umbrella.
-
Several other extensions have been renamed for consistency.
Quarkus REST, Quarkus Messaging and Quarkus REST Client are still leveraging the reactive engine underneath for efficiency and performances. At the user level, this is an implementation detail.
The configuration properties of these extensions have also been renamed to refer to the new names.
Impact on users
These changes are designed to clarify that you are not constrained to reactive programming when using these extensions. Whether you prefer a traditional blocking approach, reactive programming, or virtual threads, Quarkus has you covered.
For most projects, this renaming should not require changes, except for those having used quarkus-rest-client it may require some adjustments in your dependencies. We’re committed to making this transition as smooth as possible. Here are a few key points to help you adapt:
-
Maven relocations: We have introduced Maven relocations for the renamed extensions, guiding you toward the new names when you update your dependencies.
-
Config fallback: The old configuration properties will continue to work. It is recommended to move to the new ones though.
-
Tooling updates: The Quarkus CLI will default to use the new names for new projects but continue to work with old names.
-
Quarkus update:
quarkus updateprovides recipes to help perform the update/renames if/when relevant, including configuration properties. -
Documentation: Our documentation was updated to reflect the new extension names, making finding the right extension for your project easier.
-
Migration guide: As usual, our migration guide contains all the gory details. However, we highly recommend the use of
quarkus updateto migrate to the new names.
For current projects, we recommend continuing to use the old names if you want to remain buildable against an older version of Quarkus — otherwise, upgrade at your own pace for new names.
For new projects we will default to and recommend the new names.
What this means for you as an extension author
If you’ve developed a Quarkus extension and want to stay compatible with Quarkus LTS releases while supporting the newer versions, we recommend keeping the old names as aliases for the new ones. This will ensure that your extension remains compatible with older Quarkus versions. Relocations solve this.
For extensions targeting 3.9+, you should use the new names. Possibly make a separate branch for 3.8 and older to keep the old names.
