Given the increasing ubiquity of digital technologies, which are becoming increasingly and naturally embedded in our environment, the essential question arises as to what role Java will play in this future development of IT systems. Mark Weiser, pioneer of ubiquitous computing, described this technological paradigm shift as follows: “The best technology is the one we don’t even notice because it naturally enriches our everyday lives.” (paraphrased from [LMU19]).
Ubiquitous computing is already demonstrating how technology is becoming omnipresent and seamlessly integrated into our environment as an invisible companion. A key factor here is the almost universal access to networks (such as Wi-Fi), which is increasingly becoming standard infrastructure internationally. This access enables the real-time networking of smart devices, from smart homes to wearables, and forms the basis for technologies that work intuitively in the background and communicate with each other seamlessly without disruptive interference. In addition, ubiquitous computing promotes an ever-closer symbiosis between humans and machines, in which new technologies are emerging that are increasingly replacing classic interfaces to the digital world such as smartphones and tablets. Devices such as mixed reality glasses (e.g. Meta Quest or Apple Vision Pro) open up a new form of interaction in which digital information is projected directly and contextually into the field of vision. The goal is no longer just general interaction, but rather the precise adaptation of digital content to the individual needs of the user. This development leads to the concept of hyper-personalization: systems respond in real time to location, preferences, and goals, providing tailored information, entertainment, or support in everyday life. This points to a future in which digital experiences are seamlessly integrated into personal life.
In order to survive in an increasingly dynamic market environment, companies and organizations must no longer simply react but actively shape the future. To this end, short innovation cycles and maximum speed and efficiency in the provision of new services are becoming key success factors. However, it is precisely this requirement that presents modern software development with a familiar dilemma: developers need flexibility and speed to respond agilely to new requirements, while operations must ensure security and stability. This tension is becoming increasingly apparent, especially in an era dominated by digital platforms and cloud ecosystems. DevOps attempts to resolve this divergence by connecting development and operations through shared processes, close collaboration, and automation. Nevertheless, the central challenge remains: optimizing the so-called lead time of a requirement from idea to productive deployment.
Figure 1 shows a horizontal timeline representing the course of a development process. It is divided into two main sections: lead time and processing time. Lead time covers the entire period from the creation of a requirement to its productive deployment. Within this span, processing time marks the part in which the actual implementation, i.e., the active processing of the requirement, takes place. The remaining time consists of waiting and coordination phases that prolong the process.
As market dynamics increase, the ability to minimize lead time continues to gain importance. Modern cloud infrastructures form the foundation for this: they ensure stability, security, and flexibility and enable innovations to be implemented more quickly and reliably. The key here is to strike a balance between high development speed and consistent quality. The Reactive Manifesto (see [REA13]) provides guidance in this regard. It serves as a model for modern, networked software architectures and defines four central, fundamental principles for cloud-native applications and, in particular, for microservice-based systems:
- Message orientation: Systems communicate asynchronously and use messages to scale independently and respond flexibly to events.
- Resilience: Applications remain stable even under load and in the event of errors, as they rely on self-healing mechanisms and isolation.
- Elasticity: Systems scale dynamically with the load, both horizontally by adding components and vertically by intelligently allocating resources (e.g., replicas, etc.).
- Responsiveness: Applications respond to user requests and events in real time, enabling immediate and consistent user experiences.
Building on these principles, reactive programming has established itself as a programming paradigm that was developed specifically for processing asynchronous events and building high-performance, scalable systems. In contrast to traditional imperative programming, where commands are executed sequentially and blocking, reactive programming relies on a non-blocking, event-driven model. Data flows and changes are treated as streams that are processed as soon as new events arrive. This approach enables applications to use resources more efficiently and respond more dynamically to peak loads, as tasks no longer have to wait for each other. Reactive programming offers significant advantages, especially in the context of modern microservices architectures, by supporting technologies such as elastic scaling and resilient transactions. It thus forms a central bridge between the requirements of the Reactive Manifesto and the practical implementation of modern cloud-based systems.
The interplay between cloud infrastructures, the principles of the Reactive Manifesto, and reactive programming has a clear objective: to create efficient, resilient, and scalable systems that meet the demands of modern markets. To guarantee both speed and stability, the focus is on the key components of the cloud-native paradigm: DevOps, microservices, containerization, and continuous integration and continuous delivery (CI/CD). These pillars form the basis for agile and highly available IT landscapes that can not only be deployed more quickly but also respond dynamically to changing loads and requirements while enabling future paradigms (see above).
But it was precisely at this point that Java, long the dominant language for (large) companies and organizations, showed weaknesses. While it impressed for decades with its stability and broad support, its use in modern, container-based environments such as Kubernetes increasingly proved to be a challenge. Long start-up times, high resource consumption, and deployment complexity made life difficult for Java-based applications in a world of microservices and dynamic autoscaling. These disadvantages led developers and architects to frequently rely on non-hierarchical programming paradigms or lean frameworks to better meet the requirements of the cloud-native era.
From Weakness to Strength: How Quarkus Is Redefining Java
Quarkus, a framework developed by Red Hat specifically with containerized cloud-native applications in mind, addresses precisely this issue. The aim of this framework is to retain the advantages of Java while overcoming its weaknesses in modern infrastructures, thereby optimizing it for the needs of the cloud-native era. It thus provides an answer to the central conflict of objectives in DevOps: speed in development without compromising the stability or security of the system. Applications are prepared as far as possible at compile time, for example by Quarkus shifting decision-making processes such as dependency injection or annotation scans from runtime to build time, enabling faster, more resource-efficient applications. The result: fast start times, minimal resource consumption, and a drastic reduction in overhead costs. This is a decisive advantage, especially for containers that are frequently started and stopped to meet the requirements of an elastic infrastructure.
With support for GraalVM, Quarkus also enables applications to be compiled as native images (not to be confused with container images). These images are highly optimized binary files that do not require a JVM and are perfectly tailored for containerized environments: The startup time of such applications is often in the millisecond range. Additionally memory consumption is significantly reduced.
Traditionally, Java code is compiled into bytecode, which is then interpreted by the JVM at runtime or optimized through just-in-time compilation (JIT). This means that the final machine code generation (i.e., the executable code for the operating system and hardware) takes place while the application is running. This approach is flexible, but it costs startup time and resources because the JVM must first be loaded and initialized.
When creating a native image with GraalVM, on the other hand, the Java code is not only compiled to bytecode, but is completely converted to executable machine code at build time. The result is a standalone, native binary file that can be executed directly by the operating system without the need for a JVM. This is possible because native image compilation statically analyzes and integrates all classes, methods, and frameworks required at runtime.
A native image can be integrated into a container image as an executable, native binary file. The advantage of this is that the container image has far fewer dependencies. For example, the image does not need a JVM because the native image can already execute the Java code without it. This results in smaller container images, faster container starts, and lower resource consumption, which is essential in highly scalable and flexible environments such as Kubernetes.
A Look at the Basic Principles and Structure of Quarkus
To fully leverage the potential of Quarkus, it is worth taking a look at the inner workings of this modern framework. A solid understanding of how it works enables targeted, efficient use and tailored adaptation to individual requirements. Quarkus is based on two central principles: first-class Kubernetes-native Java and developer joy. The first principle emphasizes high performance, smooth integration into modern cloud environments, and optimized containerization. The second focuses on the developer’s experience by promoting a more productive and enjoyable way of working.
At the heart of the Quarkus architecture are two closely linked elements: Eclipse Vert.x and the Quarkus Extensions. Together, they implement the principles of the Reactive Manifesto and create a platform that offers both high flexibility and exceptional performance.
Quarkus Core forms the technical foundation. It includes key tools such as Jandex, a framework for rapid analysis and processing of annotations in bytecode, and Gizmo, a library for bytecode generation during the build. This is complemented by the Graal SDK, which prepares applications for the creation of native images. These components enable Quarkus to analyze, adapt, and optimize code as early as the build time.
Building on this, Eclipse Vert.x, as a non-blocking, event-driven runtime, ensures the reactive performance of Quarkus. It enables asynchronous processing of data streams and events, allowing resources to be used optimally and processes to be executed in parallel. Requests, data flows, and messages are treated as continuous streams that are processed in real time. Quarkus abstracts the technical complexity and provides developers with a uniform, reactive programming base that combines high performance with ease of use.
The architecture is rounded off by the Quarkus Extensions system, which simplifies the integration of external technologies and services (such as databases, security solutions, or monitoring tools). They standardize the handling of these components, automate configurations, and shift many tasks to the build phase. This results in lightweight, optimized applications that offer maximum flexibility in development mode and are designed for stability and efficiency in production mode. These extensions form the crucial link between development and operation and play a key role in seamlessly uniting both worlds. Their behavior adapts dynamically to the respective context of use. This clear separation between development mode and production mode is one of the central principles of Quarkus and ensures a balanced interplay of agility and stability.
In development mode, the focus is on speed, flexibility, and immediate feedback to promote the creative process and short iteration cycles. Production mode, on the other hand, is designed for efficiency, reliability, and optimal runtime conditions. This dual focus forms the basis for consistent deployments and a smooth transition from development to operation. It is therefore in line with modern DevOps practices.
Below, we take a detailed look at both modes to show how Quarkus specifically supports different requirements at each stage of the software lifecycle.
Extensions in Dev Mode: Efficiency Through Automatic Container Provisioning
One of Quarkus’ most outstanding features in development mode is its ability to use Dev-Services to automatically containerize and provision external services such as databases (e.g. PostgreSQL), identity providers (e.g. Keycloak), or message brokers (e.g. Kafka) and more if they are not already available. This principle was developed to provide developers with a ready-to-use environment and relieve them of the time-consuming initialization and configuration of such services.
As soon as a Quarkus extension is integrated, for example the database extension quarkus-jdbc-postgresql, Quarkus analyzes whether the required resource is already available. If, for example, an active PostgreSQL instance is missing, Quarkus automatically starts a suitable Docker container that provides the resource. The runtime environment is orchestrated with Docker (or Podman), provided these are installed on the development machine. The connection to the started container instance is also configured automatically. Developers only need to focus on their application, as Quarkus takes care of the entire provisioning and configuration.
Communication with the launched container takes place via the usual Quarkus configuration mechanisms, such as the application.properties file located in the src/main/resources directory of the Quarkus project. This file allows parameters such as database URLs or access data to be defined dynamically. Quarkus automatically updates the configuration, eliminating the need for manual adjustments or restarts. This ensures a smooth development process and promotes productivity.
Another advantage of this integration in dev mode is the consistent environment provided by Quarkus. Developers can be sure that the automatically started services accurately reflect later production conditions such as database versions or API standards. This minimizes conflicts that may arise later on from the outset.
On a technical level, the behavior of Dev-Services can be controlled via specific configuration parameters. For example, it is possible to disable Dev-Services if necessary and to use an existing infrastructure instead:
quarkus.datasource.devservices.enabled=true
This configuration value is specified in the application.properties file. The default value is true.
In Quarkus’ Dev mode, not only is development supported by the automatic provisioning of services via Dev-Services, but application testing is also seamlessly covered by the integration of Testcontainers (see [TCS23]). Testcontainers is a popular Java library that allows tests to be run in realistic, container-based environments without the need for additional manual steps. Quarkus automatically starts the necessary containers for external services such as databases or message brokers, creating a production-like, reproducible test environment. This greatly simplifies development and testing processes, as there is no need to maintain a separate test infrastructure.
In Quarkus, configurations can be specified for specific runtime profiles, such as dev, test, or prod. This is done using profile prefixes such as %test in application.properties. For example, if a PostgreSQL database is required in test mode, the following setting is sufficient to automatically provide it via test containers:
%test.quarkus.datasource.devservices.image-name=postgres:16
%test.quarkus.datasource.username=user
%test.quarkus.datasource.password=password
%test.quarkus.datasource.db-name=testdb
With this configuration, Quarkus only automatically starts a PostgreSQL test container during test execution. In development or production mode, the regular database configuration remains active. This ensures a clean separation of environments to produce reproducible and stable tests.
Extensions in Production Mode: Focus on External Service Provision
While dev mode enables the automatic provisioning of containers and services, Quarkus behaves differently in production mode. In this mode, the focus is on ensuring that external services, such as databases, identity providers, or message brokers, are already available in the target environment. In production mode, Quarkus does not manage container instances itself, but ensures that the application can interact seamlessly with the deployed services.
Configuration is also done via the application.properties file or environment variables, allowing applications to adapt flexibly to different environments. For example, cloud-native mechanisms such as ConfigMaps or Secrets can be used in Kubernetes to provide access data or connection endpoints. Once the container infrastructure is ready, Quarkus automatically accesses these resources. This ensures the stability of productive environments and, at the same time, prevents Quarkus applications from relying on potentially unsecured containers.
Another advantage of Quarkus is its ability to automatically generate IaC (Infrastructure as Code) scripts for production environments. Using specific extensions, such as the Kubernetes or OpenShift extension, Quarkus creates YAML files that describe the infrastructure required for production.
Developers can insert these generated YAML files directly into their continuous integration and deployment (CI/CD) pipelines, which significantly simplifies and accelerates the transition from development to production mode.
The Quarkus extensions are closely integrated with the build-time optimization process, analyzing source code, incorporating necessary dependencies, and automatically performing configuration tasks. Unnecessary components are removed during the build, making applications more compact and resource-efficient. This means developers have less technical complexity to deal with, while Quarkus optimizes performance and trims the code for efficiency in the background.
The integrated development tools, which consistently implement the concept of developer joy, make a significant contribution to high productivity. Live coding is particularly noteworthy: changes to the code or configurations are applied almost in real time without the need for a restart. This significantly shortens feedback cycles and keeps the focus on the actual logic of the application rather than the build process.
Another element of flexibility is the application.properties file, which is used to define central settings such as ports, database connections, and messaging parameters. It unleashes its full potential in containerized environments: configurations can be dynamically adjusted via environment variables, enabling smooth transitions between development, test, and production environments. This virtually eliminates the need for time-consuming manual adjustments during deployment.
This automation continues with tight integration with Docker and Kubernetes. Quarkus automatically generates appropriate container images and deployment manifest files during the build. This means that applications are delivered ready for containers. This is a significant advantage for continuous integration and deployment (CI/CD) processes, where speed and reliability are crucial.
Despite its modern, reactive, and cloud-native orientation, Quarkus remains fully compatible with established Java standards such as Jakarta EE and MicroProfile. Companies can continue to use existing architectures and code bases and modernize them step by step without having to completely change their technology.
With this combination of modular architecture, build-time optimization, reactive runtime environment, and developer-friendly tools, Quarkus sets a new standard for cloud-native Java applications. It combines speed with stability, reduces complexity, and provides a well-designed foundation for modern software development. Quarkus makes Java efficient, scalable, and ready for the demands of next-generation distributed systems.
Reactive Development with Quarkus in Dev Mode
The following application example shows how to create a simple task management system (to-do app) based on the principles of reactive development from the outset. The example describes the implementation of a small REST API that allows users to create, view, and delete tasks (e.g., to-do entries). Instead of tolerating blockages caused by classic, synchronous database and API calls, Quarkus’ reactive capabilities are used to process all requests efficiently and non-blockingly. Hibernate Reactive serves as a tool for communicating with the database, and Quarkus’ reactive APIs (e.g., RESTEasy Reactive) ensure that HTTP methods such as GET or POST are executed completely asynchronously.
The following explanations assume that Java is available, Quarkus is already installed, and Docker is active on the development system, as Quarkus’ Dev-Services will automatically provide the PostgreSQL database as a container.
The objective is as follows: A reactive REST API that manages tasks and interacts asynchronously with a PostgreSQL database is to be created. All responses from the API and database operations are reactive, thus conserving the application’s resources.
In the following, the Quarkus CLI is used to create a new project with the necessary reactive extensions. These extensions enable us to use the desired reactive functionality for REST, Hibernate, and the database:
quarkus create app com.example.todo-reactive --extensions="resteasy-reactive, hibernate-reactive-panache, reactive-pg-client"resteasy-reactive:Provides a reactive implementation of JAX-RS for RESTful APIs.hibernate-reactive-panache:Enables non-blocking ORM functionality based on Hibernate.reactive-pg-client:Provides a reactive PostgreSQL client to execute queries asynchronously.
In the next step, a database entity src/main/java/com/example/todo/Task.java is created, which can be processed with Hibernate Reactive. Thanks to Panache extensions, working with database models is clearly structured and offers reactive support. The source code for this entity is as follows:
package com.example.todo;
import io.smallrye.common.annotation.Blocking;
import io.quarkus.hibernate.reactive.panache.PanacheEntityBase;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;
@Entity
public class Task extends PanacheEntityBase {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
public Long id;
public String description;
public boolean completed;
}PanacheEntityBaseoffers a range of predefined methods such aspersist()orfindAll(), which automatically return reactive streams and operate in a non-blocking manner.- Hibernate Reactive ensures that all database calls are executed asynchronously and in a resource-efficient manner.
The REST controller src/main/java/com/example/todo/TaskResource.java handles requests such as retrieving all tasks, adding new tasks, and deleting individual entries in a fully reactive manner.
package com.example.todo;
import io.smallrye.mutiny.Uni; // Reactive API for asynchronous data processing
import jakarta.transaction.Transactional;
import jakarta.ws.rs.*;
import jakarta.ws.rs.core.MediaType;
import java.util.List;
@Path("/tasks")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class TaskResource {
@GET
public Uni<List<Task>> listAll() {
return Task.listAll(); // Returns a reactive Uni instance
}
@POST
@Transactional
public Uni<Task> create(Task task) {
return task.persist().replaceWith(task); // Persists asynchronously and
returns the task
}
@DELETE
@Path("/{id}")
@Transactional
public Uni<Void> delete(@PathParam("id") Long id) {
return Task.findById(id).onItem().ifNotNull().transformToUni(task ->
task.delete()).replaceWithVoid(); // Deletes the task asynchronously
}
}As you can see, the logic of this controller is based on Uni, a class of the Mutiny API used for asynchronous and reactive programming in Quarkus. All method returns are non-blocking and are processed asynchronously by Hibernate Reactive.
The application.properties file controls the automatic configuration. For development, a PostgreSQL container is automatically started using Dev Services:
quarkus.datasource.db-kind=postgresql
quarkus.datasource.devservices.enabled=true
quarkus.hibernate-orm.database.generation=drop-and-create- Quarkus recognizes from the configured data source that a PostgreSQL database is required and automatically starts a suitable container.
- The
drop-and-createsetting creates the database fresh for each new session, which is helpful during development.
The application can now be started in dev mode:
./mvnw quarkus:dev
Quarkus automatically starts the application and PostgreSQL container through Dev Services. Changes to the code are applied immediately without the need to restart.
This example shows how easy it is to design a fully reactive application with Quarkus. Thanks to Hibernate Reactive, Panache, and RESTEasy Reactive, all requests are processed asynchronously, which not only increases efficiency but also ensures a scalable architecture. Combined with Dev Mode and automated Dev Services, Quarkus offers a user-friendly platform for modern, reactive software development.
The Strategic Advantages of Quarkus
The advantages of Quarkus go far beyond technical details. They have a direct impact on economic efficiency and competitiveness. The fast start-up time and low resource consumption significantly reduce operating costs. This is a crucial factor in cloud environments, where companies often pay according to a pay-as-you-go model.
In addition, Quarkus integrates seamlessly into common DevOps processes. The build time optimizations are a natural advantage in the context of CI/CD pipelines, as they eliminate long start times for tests and deployments. The ability to use GraalVM Native Images is also a perfect fit for serverless architectures, where short start times are a prerequisite for cost efficiency.
Last but not least, Quarkus offers developers a platform for turning innovative ideas into reality more quickly. Minimizing overhead in the development phase and seamless integration into cloud-native infrastructures such as Kubernetes give teams the flexibility they need to implement rapid iterations and experimental projects. Quarkus not only overcomes the barriers of the traditional Java world, but also proves to be a strategic tool that helps companies remain competitive in the age of microservices, containerization, and cloud computing.
Quarkus is therefore much more than a framework. It is a powerful tool for those who want to lead Java into the future. And it forces companies and developers alike to rethink their assumptions about Java. Quarkus impressively demonstrates that even an aging ecosystem like Java can always be reinvented to meet the demands of the next technological era.
