Quarkus is a full-stack Java framework for cloud-native applications, including microservices, serverless services, and monoliths. It targets fast startup and a small resource footprint without requiring every application to run on Kubernetes. section 1.8 section 1.2.1
The central design choice is to do framework work at build time rather than repeat it at every startup. Quarkus processes code metadata, annotations, and configuration while packaging the application, then carries the results into the runnable artifact. This reduces startup work and avoids including code needed only for initialization. section 1.1 section 2.5
Figure 2.7 Quarkus build time vs. runtime processing. Quarkus moves as much processing as possible to build time.
The build-time-versus-runtime diagram shows where Quarkus moves application processing to shorten startup. section 2.5
A Quarkus application can run on OpenJDK HotSpot or be compiled into a GraalVM native executable. Native compilation is useful when startup matters most, as in serverless deployments; JVM execution may be preferable when throughput matters more. Native-image builds need additional tooling and configuration, though Quarkus supplies much of the required integration. section 1.2.2
The platform combines familiar Java APIs with development and build tooling:
- Extensions add selected capabilities, such as integration or security, instead of requiring every application to include the whole ecosystem. section 1.4
- Jakarta EE and MicroProfile standards, alongside libraries such as Hibernate and RESTEasy, let developers reuse established APIs in JVM and native modes. section 1.2.3
- Dev mode applies code and configuration changes during a running development session, providing a short feedback loop without a manual restart. section 1.1
- Applications can use imperative or reactive programming, or combine them; virtual threads are also supported, with limitations to consider. section 1.3.1
Start and package an application
Generate a starter project with the Quarkus Maven plugin, Quarkus CLI, or graphical starter. Package it as a runnable JAR, or build a native executable. If GraalVM is not installed locally, a container build can produce a Linux-specific native executable; for Maven, run `./mvnw package -Pnative -Dquarkus.native.container-build=true`. This route requires Docker or Podman. section 2.1 section 2.4.5
A car-rental system provides a larger application context: Quarkus microservices communicate through other services and brokers, while a separate Quarkus CLI groups inventory operations. The example illustrates how a small starter grows into a system using multiple integrations; it is deliberately more complex than many real-world applications need to be. section 1.5.2
