A native executable is a platform-specific machine-code build of a Quarkus application. GraalVM native-image compiles Java code ahead of time and includes the application code, required library code, language runtime, and linked JDK code. Closed-world analysis determines what the executable needs at run time. Unlike a runnable JAR, it runs without starting a JVM; a binary built for Linux will not run on Windows. section 2.4.1 section 2.4.2
To build and run one from a generated Quarkus project:
- Use `./mvnw package -Pnative`, `./gradlew build -Dquarkus.package.type=native`, or `quarkus build --native`. section 2.4.4
- Run the generated binary directly, for example `./target/quarkus-in-action-1.0.0-SNAPSHOT-runner`. Its filename may differ by platform. section 2.4.4
- Allow more build time and memory than for ordinary packaging; native compilation can take several minutes. section 2.4.4
If GraalVM or Mandrel is unavailable locally, Quarkus can build inside Docker or Podman. Request this with `-Dquarkus.native.container-build=true`; Quarkus may also fall back to a container build when it cannot find `native-image`. This route produces a Linux executable, suitable for a Linux-based container image even when the host uses another operating system. section 2.4.5
Choose the format for the workload, not as an automatic final step. Fast startup makes native executables attractive for serverless deployments. A long-running JVM application can eventually achieve higher throughput through just-in-time optimization, while native compilation fixes its optimizations ahead of execution. section 2.5.1 section 1.2.2



