Now let’s produce a native executable for our application. It improves the startup time of the application and produces a minimal disk footprint. The executable has everything needed to run the application including the JVM (shrunk to be just enough to run the application) and the application itself.
The output should be similar to the following (the relevant part is that it indicates it's using the GraalVM):
openjdk version "11.0.11" 2021-04-20 OpenJDK Runtime Environment GraalVM CE 21.1.0 (build 11.0.11+8-jvmci-21.1-b05) OpenJDK 64-Bit Server VM GraalVM CE 21.1.0 (build 11.0.11+8-jvmci-21.1-b05, mixed mode, sharing)
Building the Native Image
pom.xmlis the declaration for the Maven profile named "native":
<profile> <id>native</id> <activation> <property> <name>native</name> </property> </activation> <build> ... <properties> <quarkus.package.type>native</quarkus.package.type> </properties> </profile>
We use a profile because packaging the native image takes a few seconds. However, this compilation time is only incurred once, as opposed to every time the application starts, which is the case with other approaches for building and executing JARs.
quarkus.native.container-runtime. This example uses Podman, so if you're using Docker be sure to update the command accordingly.
mvn clean package -Pnative -DskipTests -Dquarkus.native.container-runtime=podman
In addition to the other JARs normally produced by the
package goal, the native profile creates a file named
Running the Native Image
CTRL-Cin its terminal.