Quarkus 2.0 Delivers Continuous Testing, CLI and Supports Minimal JDK 11

Nineteen months after its first major release, Red Hat has released Quarkus 2.0 with new features such as continuous testing, a new CLI, JDK 11 as a minimal version, and dependency upgrades to Vert.x 4.0 and MicroProfile 4.0.

Quarkus, the application development framework that started its journey towards making Java the preferred tool for Kubernetes-native development, has reached another important milestone. All the features added to version 2.0 promise to "bring Quarkus to a whole new level while keeping its roots: fast boot, low memory usage, and developer joy."

This version moves the minimal JDK version to 11, however, the Quarkus 1.13 release train still supports JDK 8. As a major release, one would also expect breaking changes, but Red Hat’s promise is that developers should expect a smooth upgrade.

In order to better understand the benefits of this new version, InfoQ reached out to the Quarkus core team members to provide a brief description of the benefits of each newly added feature in Quarkus 2.0.

Continuous testing, a feature that could provide a boost in efficiency, allows tests to be run automatically in development mode while writing code. Stuart Douglas, senior principal software engineer at Red Hat, having recently discussed continuous testing, told InfoQ:

Stuart Douglas: Continuous Testing allows developers to get instant focused feedback on their changes. Whenever you modify some code the relevant tests for that bit of code are run (and only the relevant tests), and the results displayed in a status bar. As long as the code you are working on is tested you can get instant feedback, without needing to manually run tests or look at your changes in a browser.

Another improvement focused on testability are changes to DevServices that allow automatic wire-up connections to databases and message queues in development and test modes. Georgios Andrianakis, principal software engineer at Red Hat, told InfoQ:

Georgios Andrianakis: Almost all applications need to communicate with some sort of database or message broker in order to be functional. This means that developers need to properly setup and tear down these services when they are developing their applications or running their tests.

DevServices was developed in order to remove the need of manually running these external services while developing a Quarkus application.

In practical terms, this means that a developer can use mvn quarkus:dev and mvn test (or their Gradle or Quarkus CLI equivalents) without starting the necessary databases or message brokers beforehand and without needing to configure the URL of these services. The only requirement is a running Docker installation, as the feature depends on Testcontainers.

It’s worth mentioning that users can easily disable this feature either explicitly or implicitly by configuring a specific URL for the service they don’t want handled by DevServices.

The new Quarkus CLI intends to improve developers’ productivity. Even though its broad availability for consumption on all systems is still a work-in-progress, it can be already run by using JBang. With this new feature, Quarkus removes the need for Maven or Gradle commands. Erin Schnabel, senior principal software engineer at Red Hat, told InfoQ:

Erin Schnabel: The CLI is intended to simplify working with quarkus projects. Using it isn't required, the Maven and Gradle plugins will continue to work just fine, but our goal with the CLI is to simplify and streamline things whenever possible. The CLI commands provide consistency and brevity for common tasks regardless of which build tool the project uses (for example,. mvn io.quarkus:quarkus-maven-plugin:2.0.1.Final:create … vs. quarkus create). As extensions are the integration key for Quarkus, the CLI allows by using quarkus extension or quarkus ext to manage extensions: adding, removing them from the project. The future of the CLI is targeted at simplifying the options, like creating native images or remembering your favorite settings.

For developers who prefer interaction through a visual user interface (UI), there were also changes to the Quarkus DevUI. Stephane Eparduad, principal software engineer at Red Hat, told InfoQ:

Stephane Epardaud: The Quarkus DEV Mode comes with a lot of great features from the console: terse, nicely coloured logs, as well as Continuous Testing reports and commands, but you can’t display everything on the console. For everything that can help developers presented in a graphical manner, we have the DEV UI. If you go to http://localhost:8080/q/dev you are presented with a graphical list of all the extensions you have installed on your running Quarkus application. Along with each extension, you get links to their documentation and specific pages, such as the Swagger UI to test your REST endpoints, or the GraphQL UI, a list of existing REST endpoints and their performance scores, the list of installed CDI beans, and naturally, the Continuous Testing UI presented in a graphical manner. A lot of extensions support the DEV UI to help you develop your Quarkus application, and every new release adds more custom DEV UI pages and actions, so make sure to check it out.

Among other important changes, there were updates to the SmallRye components. Roberto Cortez, principal software engineer at Red Hat, told InfoQ:

Roberto Cortez: SmallRye provides APIs and implementations tailored for Cloud development, including, but not limited to MicroProfile. A lot of our users are not aware that SmallRye contributes a significant number of features to the Quarkus platform. For instance, everything related to configuration is provided by SmallRye Config. Talking about configuration, we have introduced a way to map configuration values as a static type-safe object with the @ConfigMapping annotation. We are working on making the SmallRye APIs more reactive-friendly, so health endpoints required by Kubernetes are non-blocking, and allow usage of fault-tolerance annotations on reactive methods.

We cannot forget SmallRye Reactive Messaging, which leverages the new Vert.x 4.0 APIs and SmallRye Mutiny to improve the Event-Driven Reactive Programming model. In other areas, we added OpenTelemetry support which should integrate seamlessly with the rest of the Quarkus ecosystem for tracing and monitoring needs.

Another area with significant improvements is SmallRye GraphQL. Quarkus 2.0 contains a new extension specifically for the GraphQL client. This extension offers capabilities needed to easily execute queries on remote GraphQL services. It offers two types of clients, depending on which one fits your use case better - typesafe and dynamic. The typesafe client works directly with model classes and is thus similar to a MicroProfile REST client, but made for GraphQL. On the other hand, the dynamic client works on a more abstract level where the data in play is represented as JSON objects, and GraphQL queries are built using a specialized domain-specific language. Both client-side and server-side GraphQL extensions now also offer GraphQL subscriptions, so clients can listen to real-time events from the server. This greatly enhances reactive programming capabilities.

Another important niche change is the support for Kotlin coroutines with extensions such as RESTEasy Reactive, REST Client and Reactive Messaging. Justin Lee, principal software engineer at Red Hat, told InfoQ:

Justin Lee: Quarkus has, since its first release, supported Kotlin but a major piece was missing: Kotlin coroutines. With recent improvements in GraalVM native-image and us having improved the set of extensions with reactive support, we now are able to support coroutines. The win here is that coroutines provide a simpler way to write and maintain reactive friendly code compared to using the Java language. This should improve when Project Leyden lands in the Java SDK, but until then, you can mix and match using the style that works best for you, reactive or imperative API, using both Java or Kotlin with Quarkus 2.0.

Furthermore, we’ve fixed lots of bugs and polished the Kotlin integrations allowing for much tighter integration such that Quarkus features, like devmode, works with Kotlin.

Along with the dependency upgrades to Vert.x 4.0 and MicroProfile 4.0, other notable features include: a dependency upgrade to Hibernate ORM 5.5 with support for metadata contributors on the Hibernate ORM extension; Quarkus’s implementation of CDI, ArC, now supports CDI decorators; transaction support for MongoDB with Panache; and a new Amazon SSM extension.

It is also recommended to use GraalVM 21.1, the latest version, with Quarkus 2.0.

The framework that calls itself "supersonic, subatomic Java" Quarkus has grown in popularity, having quickly moved into the Early Adopters space, as per the 2020 Java InfoQ Trends Report. In the 19 months since the release of Quarkus 1.0, its built-in development mode has added state preserving hot deploy and redeploy features, continuous testing, and a CLI. Recent surveys such as the Snyx JVM Ecosystems Report 2021 and the 2021 JRebel Java Technology Report, place Quarkus with a market share of 11% and 6%, respectively.