Build Even Faster Quarkus Applications With fast-jar

Quarkus is already fast, but what if you could make inner loop development with the supersonic, subatomic Java framework even faster? Quarkus 1.5 introduced fast-jar, a new packaging format that supports faster startup times. Starting in Quarkus 1.12, this great feature became the default packaging format for Quarkus applications. This article introduces you to the fast-jar format and how it works.

Note: The ninth annual global Java developer productivity report found that more developers are implementing business applications with Quarkus. Quarkus’s support for live coding with fast startup and response times lets developers focus more on business logic implementations rather than wasting time on jobs such as recompiling and redeploying code and continuously restarting the runtime environment.

The Custom Class Loader

To understand fast-jar's secret solution, you need to understand the purpose of the Java class loader and what it processes when a Java application starts up. The Java class loader dynamically loads Java classes into the Java Virtual Machine (JVM) in a Java Runtime Environment (JRE). The Java class loader handles these functions so that the Java runtime doesn’t need to know where the files and file systems are. Unfortunately, the class loader loads slower for Java applications with more dependencies. The reason is that the class loader typically takes the O(n) Big O notation on the number of Java application dependencies.

Quarkus’s fast-jar format solves this problem! When you create an application using the fast-jar format, Quarkus uses a custom ClassLoader that already knows the entire classpath when the application is built. The ClassLoader indexes the location of classes and resources that are written at build time, and the location is read at startup time.

By following the next steps, you can learn for yourself the differences between the legacy JAR format and the new fast-jar format.

Step 1: Create 2 Quarkus Projects With Multiple Extensions

First, use a Maven plugin to scaffold a new project based on Quarkus 1.11.6.Final, which uses the legacy JAR packaging format:

$ mvn io.quarkus:quarkus-maven-plugin:1.11.6.Final:create \
    -DprojectGroupId=org.acme \
    -DprojectArtifactId=getting-legacyjar-started \
    -DclassName="org.acme.getting.started.GreetingResource" \
    -Dextensions="infinispan-client,rest-client,openshift, resteasy-jackson" \
    -Dpath="/hello"

This command generates a getting-legacyjar-started directory that pulls down infinispan-client, rest-client, openshift, and resteasy-jackson extensions into the new Quarkus project.

Next, create another project based on Quarkus 1.12.2. Final, with the new fast-jar format:

$ mvn io.quarkus:quarkus-maven-plugin:1.12.2.Final:create \
    -DprojectGroupId=org.acme \
    -DprojectArtifactId=getting-fastjar-started \
    -DclassName="org.acme.getting.started.GreetingResource" \
    -Dextensions="infinispan-client,rest-client,openshift, resteasy-jackson" \
    -Dpath="/hello"

This command generates a getting-fastjar-started directory that includes the same extensions, but uses the fast-jar packaging format.

Step 2: Package the applications to compare formats

Next, we’ll package the applications to compare how differently Quarkus generates classes and resources using the legacy and fast-jar packaging formats. Package the legacy JAR application first, using the following Maven command:

$ mvn package -f getting-legacyjar-started

The output should end with BUILD SUCCESS. Then, the runnable JAR will be packaged directly in the target directory where other resources such as lib and classes are also created:

$ ls -al getting-legacyjar-started/target            
...
drwxr-xr-x   5 danieloh  staff     160 Mar 15 00:31 classes
drwxr-xr-x  67 danieloh  staff    2144 Mar 15 08:35 lib
-rw-r--r--   1 danieloh  staff  249897 Mar 15 08:35 getting-legacyjar-started-1.0.0-SNAPSHOT-runner.jar
...

Now, package the fast-jar application:

$ mvn package -f getting-fastjar-started

Once the build completes, you will find a new self-contained quarkus-app folder in the target directory:

$ ls -al getting-fastjar-started/target/quarkus-app        
...

drwxr-xr-x  3 danieloh  staff   96 Mar 15 14:25 app
drwxr-xr-x  4 danieloh  staff  128 Mar 15 14:25 lib
drwxr-xr-x  4 danieloh  staff  128 Mar 15 14:25 quarkus
-rw-r--r--  1 danieloh  staff  621 Mar 15 14:26 quarkus-run.jar
...

Step 3: Compare the application startup times

Now, let’s run both applications with the packaged JAR file to see how quickly each one starts. Run the legacy-jar application first:

$ java -jar getting-legacyjar-started/target/getting-legacyjar-started-1.0.0-SNAPSHOT-runner.jar

Once the application starts, you will see 1.276 seconds as the boot time, as shown below (the elapsed time could be a bit different depending on your environment):

INFO  [io.quarkus] (main) getting-legacyjar-started 1.0.0-SNAPSHOT on JVM (powered by Quarkus 1.11.6.Final) started in 1.276s. Listening on: http://0.0.0.0:8080

To do a quick sanity test, you can access the RESTful API using a curl command. Then, you will see the following output:

$ curl http://localhost:8080/hello

Hello RESTEasy

Stop the development mode by pressing CTRL + C on your keyboard. Then, run the fast-jar application:

$ java -jar getting-fastjar-started/target/quarkus-app/quarkus-run.jar

Once the application starts, you will see 0.909 seconds as the boot time, as shown below (the elapsed time could be a bit different depending on your environment):

INFO  [io.quarkus] (main) getting-fastjar-started 1.0.0-SNAPSHOT on JVM (powered by Quarkus 1.12.2.Final) started in 0.909s. Listening on: http://0.0.0.0:8080

The new fast-jar custom ClassLoader delivers a startup time that is 360 milliseconds faster than the legacy JAR application. When you access the endpoint (/hello), you will have the same output (Hello RESTEasy) as the legacy JAR application.

The fast-jar format allows the default ClassLoader to keep a minimum number of JARs open for fitting in a container-layering architecture. It also doesn’t need to look up the entire classpath for missing resources in known directories such as META-INF/services.

Conclusion

In this article, you learned why applications packaged with fast-jar are faster than those packaged with Quarkus’s legacy JAR format. We also did a quick exercise so you could compare the startup times for yourself.

While we didn’t explore this option, you might have almost the same startup time if you run both applications in development mode because development mode doesn’t use a JAR file for packaging. This enhancement is intended for a production environment.

The fast-jar format is useful for applications with many extensions and dependencies, and the advantages are even greater for applications deployed to a container environment like Red Hat OpenShift. Visit the Quarkus landing page to get started with your next Quarkus journey.

This article is originally published by myself here.