fetched at April 8, 2021
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
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.
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
Step 1: Create two 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
resteasy-jackson extensions into the new Quarkus project.
Next, create another project based on Quarkus 1.12.2.Final, with the new
$ 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
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
$ 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
$ 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
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.
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
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.
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.
The post Build even faster Quarkus applications with fast-jar appeared first on Red Hat Developer.Visit Link