Get best of the week

Native compilation in Quarkus - why it matters

Hello everyone! This is the second post from our Quarkus series - today we’ll talk about native compilation. (By the way, register and go to our webinar “ This is Quarkus - Kubernetes native Java framework ”, which will be held on May 27. We will show how to start from scratch or transfer ready-made solutions)



Quarkus is a Java stack tailored for Kubernetes. And although, of course, much remains to be done here, we have worked out a lot of aspects well, including optimizing the JVM and a number of frameworks. One of the features of Quarkus that caused increased interest from developers was a comprehensive seamless approach to turning Java code into executable files for a specific operating system (the so-called "native compilation"), similar to C and C ++, where such compilation usually occurs at the end of a cycle of assembly, testing, and deployment.

Although native compilation, as we show below, is important, it should be noted that Quarkus really works well on the most common OpenJDK Hotspot Java machine, thanks to the performance improvements that we have implemented throughout the stack. Therefore, native compilation should be considered as an additional bonus that can be used at will or need. In fact, with regard to native images, Quarkus relies heavily on OpenJDK. And dev mode, warmly received by developers, provides almost instant testing of changes due to the developed features of dynamic code execution implemented in Hotspot. In addition, when creating native GraalVM images, the OpenJDK class library and HotSpot features are used.

So why then do you need native compilation if everything is already perfectly optimized? We will try to answer this question below.

Let's start with the obvious: Red Hat has extensive experience optimizing JVMs, stacks, and frameworks during the development of the JBoss project , including:


We have been dealing with the problems of running Java applications in the cloud and on devices with limited resources (read, IoT) for many years and have learned to squeeze the maximum out of the JVM in terms of performance and memory optimization. Like many others, we have long been working with native compilation of Java applications through GCJ , Avian , Excelsior JET and even Dalvik and are well aware of the pros and cons of this approach (for example, the dilemma of choosing between versatility "build once - run-anywhere" and that compiled applications are smaller and run faster).

Why is it important to consider these pros and cons? Because in some situations, their ratio becomes crucial:

  • , serverless/ , ( ) , . , . JVM , , , 5 . , Java- ( , , OpenWhisk Knative), JVM . , , .
  • , , . , JVM , , Linux’ – . Java-. , JVM, . , .
  • , - , . 12 , Kubernetes Java- . , , , , . , dead-code elimination, ( JDK), . Quarkus .

Actually, the above arguments are already enough to understand the justification of the native compilation from the point of view of the Quarkus project participants. However, there is one more, not technical, but also important reason: in recent years, many programmers and development companies have abandoned Java in favor of new programming languages, believing that Java, along with its JVM, stacks and frameworks, has become too voracious in terms of memory, too slow etc.

However, the habit of using the same tool to solve any problems is not always right. Sometimes it’s better to step back and look for something else. And if Quarkus makes people pause and think, this is good for the entire Java ecosystem. Quarkus embodies an innovative perspective on how to create more efficient applications, making Java more relevant to new application architectures like serverless. In addition, due to its extensibility, Quarkus, we hope, will acquire an entire ecosystem of Java extensions, significantly increasing the number of frameworks that out of the box will support native compilation as part of applications.

More articles:


All Articles