Showcasing the maturity and evolution of critical developer productivity capabilities within Quarkus.
Since its inception, Quarkus has focused on more than just delivering sets of features. Developer productivity and joy have been critical components of Quarkus. The developer experience and how to improve it are carefully considered with every new feature added. This article showcases the maturity and evolution of developer productivity capabilities within Quarkus from inception to the newly-released version 2.0.
Quarkus rests on a vast ecosystem of technologies, standards, libraries, and APIs, making Quarkus “familiar” but “new”. Developers don’t have to spend lots of time learning an entirely new set of APIs and technologies to take advantage of the benefits Quarkus brings to the JVM or native images. Instead, developers can utilize their existing knowledge and skills. Among the specifications and technologies underlying Quarkus are Eclipse MicroProfile, Eclipse Vert.x, Contexts & Dependency Injection (CDI), JAX-RS, the Java Persistence API (JPA), the Java Transaction API (JTA), Apache Camel, and Hibernate, just to name a few.
Every feature should be simple, have little-to-no configuration, and be as intuitive as possible to use. It should be trivial to do trivial things while relatively easy to do more complex things, allowing developers more time to focus on their domain expertise and business logic.
One major productivity issue that most Java developers face today is the traditional Java development workflow. For most developers, this process looks like Figure 1.
Figure 1 – Typical Developer Workflow
The issue is that the Compile and Deploy / Run cycles can sometimes take up to a minute or more. This delay is wasted time where a developer could be doing something productive. Quarkus’s Dev Mode / Live Coding feature, introduced in the initial Quarkus release, solves this issue. Capabilities similar to those provided in the Node.js ecosystem were now brought to Java.
Simply run the command
./mvnw compile quarkus:dev, and Quarkus will automatically detect changes made to Java files, including class or method refactorings, application configuration, static resources, or even classpath dependency changes. When such a change is detected, Quarkus transparently re-compiles and re-deploys the changes while also preserving the previous state of the application. Quarkus re-deployments typically happen in under a second. Using Quarkus, this process looks like Figure 2.
Figure 2 – Quarkus Developer Workflow
Following the philosophy of simplicity and enhancing developer productivity, building an application into a native image is extremely simple. All the heavy-lifting and integration to consume GraalVM is done for you by the Quarkus build tools via Maven or Gradle. Developers or CI/CD systems simply need to run a build, just like any other Java build, to produce a native executable. Testing an application as a native image is also just as simple.
The Quarkus team received much praise for the live coding feature. The next logical step for improvement was to extend the live coding capability to Quarkus applications running in a remote container environment. This enhancement, known as remote dev mode, would allow developers to use the same local IDE, but the application would be running in a “real” environment with access to services that may not be available or easy to create on a local developer machine.
Instead of running
./mvnw compile quarkus:dev, a developer can run
./mvnw quarkus:remote-dev to enable the feature. Changes made on the local development machine are automatically pushed to the running remote Quarkus application in real-time. This feature significantly enhances the development loop when building Kubernetes-native applications by drastically reducing the time needed to develop and test changes before committing to source control.
See Daniel Oh’s article “Enhancing the development loop with Quarkus remote development” for a step-by-step tutorial on this feature.
Running Quarkus in dev mode enables the Quarkus Dev UI. The Dev UI, shown in Figure 3, is a landing page exposed at the
/q/dev URI for browsing endpoints offered by various extensions. The Quarkus Dev UI allows developers to quickly visualize all the extensions currently loaded, see their status, and go directly to their documentation. Additionally, each extension can add custom runtime information in the overview, full custom pages, and interactive pages with custom actions.
The Dev UI provides easy access to all the application’s configurations, shown in Figure 4. Any changes made in the UI are reflected in
application.ymlif using the Quarkus YAML extension).
Additionally, the Dev UI provides streaming access to the application’s log file and quick access to the application’s test suite. A developer can toggle test execution on and off, trigger test execution, and view the current test execution status within the UI, shown in Figure 5.
Quarkus continues to enhance developer productivity with the introduction of Quarkus Dev Services. When running Quarkus Dev Mode or when running tests, Quarkus Dev Services will automatically bootstrap a database container image and set all of the required configuration properties for the dev profile. Quarkus will additionally terminate the database container upon shutdown of Dev Mode.
The Quarkus Dev Services uses Testcontainers internally to bootstrap the database when running Quarkus Dev Mode or executing tests. No additional setup or configuration for Testcontainers directly is needed. If a specific image is not provided, Quarkus will choose one based on the database driver found on the classpath. The database driver could be one of the JDBC drivers or a reactive driver.
This capability grants developers a tight feedback loop and removes the additional overhead of starting a database manually and providing configuration for it. Future Quarkus versions will extend this capability to include other middleware, such as Apache Kafka and other message brokers.
Developer experience and productivity have been one of the main focuses of Quarkus since its inception. The continuous testing feature takes it to the next level. This feature enables test-driven development within Dev Mode by understanding which tests are affected by classes and methods within the application. As changes are made to the application source code, Quarkus can automatically rerun affected tests in the background, giving developers instant feedback about code changes they are making.
The continuous testing feature is integrated directly into the core of Quarkus. This integration means there are no IDE or build plugins required to enable the feature. Any user who can run command-line applications can use it. The continuous testing feature is available automatically, but the user needs to press a key during Dev Mode to enable it. It can, however, be configured to always enable it.
No technology is really complete unless it has a command-line interface (CLI) correct? It is completely possible to build and interact with Quarkus applications via its CLI. The Quarkus CLI makes it really easy to create new projects and interact with existing ones by easily adding/removing extensions, building the project, and starting Dev Mode. Additionally, developers can use the CLI to list and search for available extensions.
See the Quarkus CLI guide for more information on how to install and use the Quarkus CLI.
Quarkus was originally introduced to the open source community in March of 2019. Since then, Quarkus has evolved at an extremely fast pace, going through many iterations in a short period of time. Each iteration builds on top of the core developer productivity tools unique to Quarkus, making developer’s lives easier and more productive. Quarkus 2.0 is certainly no exception! Try it out for yourself!
Department of Information Technologies: https://www.ibu.edu.ba/department-of-information-technologies/