Qaurkus is heading towards the final version, currently reaching 3.0.0.Alpha5. InfoQ reached out to Max Rydahl Andersen, Quarkus co-lead and distinguished engineer at Red Hat, to learn more about the features that would improve the developer experience.
In our previous conversation, we focused on the technical changes that they consider to be the following steps to deliver on their mission. More than speed and cloud nativeness, developer joy and support for both reactive and imperative coding styles that are part of Quarkus’ mission statement, Developer Experience (DX) and the focus on productivity were also an important part of each of the previous major releases. To find out whether version 3.0 will follow this tradition, InfoQ continued the conversation with Andersen.
InfoQ: Quarkus 2 delivered continuous testing as part of your promise for a joyful Developer Experience. Is there anything prepared for 3.0?
Max Rydahl Andersen: Quarkus has three capabilities that enhance the developer’s productivity:
- Continuous testing
- Dev Services
- Hot-reloading experience
They allow you to explore and try things out without complex setup, restart and still apply TDD. Next, we focus on improving their integration as well as their visual experience.
The Dev UI is built around the Qute template concept, which is "tiles" that provide development-relevant information. Even though it was easy to add content, it required a lot of duplication and some workflows were just impossible to implement. We intend to have a more common structure and also use more advanced client-side technologies for a richer experience.
To enable an improved update flow, we explore the idea of a plugin mechanism for the CLI to allow integration of externally provided tooling to help during development.
InfoQ: Is Kotlin’s growing popularity reflected in Quarkus’ user habits? How about Scala?
Andersen: Each reported issue requires a reproducer project: Java leads the pack while Scala has just a few patches (for Scala 3 for instance). Kotlin has increased traction, enough to allocate dedicated engineering time to improving the experience. For example, hot-reload was improved. Also, we explore ways of improving the usage of coroutines and reactive code in Kotlin.
InfoQ: How about imperative vs. reactive programming?
Andersen: Technically, everyone uses reactive indirectly: the framework was built on a reactive core. Users can choose to write the business logic imperatively (AKA blocking) or reactively either with SmallRye Mutiny or Kotlin Coroutines. In the foreseeable future, the three models will be available. Rather than an ideology or preference, you should approach it pragmatically depending on the type of application. For instance, a primarily event-driven application has more sense to be reactive, whereas a traditional CRUD REST microservice may only use it for specific calls perhaps around 15-30%.
Starting with 2.x, Quarkus’ default REST stack is reactive, but users can opt for imperative for their business logic.
A similar hot topic is the use of virtual threads. The output of Project Loom promises to have the simplicity of imperative with performance similar to reactive without the mental overhead of reactive programming. We have limited early support for virtual threads - limits in the Java Development Kit keep virtual threads from being a drop-in replacement.
InfoQ: Does Quarkus 3.0 take further steps on the super-sonic start-up time promise?
Andersen: We continuously aim to improve the performance. But, we recently hit a plateau - the improvements were not showing up as we had expected. We started investigating when we realized that other non-JVM solutions don’t have similar problems. That led to Francesco Nigro’s (re)discovery of a long-time bug related to JVM optimization of
instanceofchecks. We’ve applied many updates to libraries used by Quarkus to reduce the impact. We worked with the OpenJDK team to get it fixed and hopefully also backported to future Java releases.We target to support
io_uring, a feature using modern OS kernels that allows having shared ring buffers between the kernel and application avoiding expensive copy operations. It is a game changer for improving response time and reducing latency.Finally, the upgrade to Hibernate 6 allows us to renounce the workarounds in Hibernate 5 related to startup and native image improvements. With Hibernate 6, we can use the "plain" version which comes with its own set of new features and Hibernate-specific improvements.
More than just features and tools, Quarkus’ third milestone brings changes to the documentation as well as following the Diataxis framework principles. And, to make the migration for existing users, tooling for migration is also available. Developers are encouraged to experiment and share feedback with the team.