Towards faster builds

A lot of effort was invested in optimizing various parts of the build process: reducing memory allocations and optimizing algorithms and data structures were a big part of it.

This work resulted in numerous pull requests across Quarkus, Jandex, and even ByteBuddy.

Our build process is already massively parallelized, but we identified a few areas where this was not the case, for example, the generation of Hibernate ORM proxies. We fixed that.

Another area for improvement was the creation of large JAR archives, which is inherently slow because it involves reading and compressing a significant number of resources, making it both I/O- and CPU-intensive. Until now, we were building JARs using a ZipFileSystem, adding resources one by one in a single thread. We have since switched to using the parallel compression support provided by Commons Compress.

This change required some fairly extensive refactoring of the JAR assembly code, but it was definitely worth it.

With all these optimizations, the time spent in the various goals of the quarkus-maven-plugin was cut in half compared to our reference version, 3.25.1. That’s great…​ but building our sample application still took around two minutes, which is more than we would like.

It’s time to step back and look at the bigger picture.

For Quarkus applications, we build our own JARs for two main reasons:

This is the process we optimized by leveraging the parallel compression support provided by Commons Compress.

However, when using Maven, a Quarkus application is still a traditional jar Maven project. It follows the standard lifecycle for the jar packaging, which means Maven will also build a conventional JAR using the maven-jar-plugin.

Taking a step back, we actually don’t need this JAR in 99% of cases, so we should avoid building it (while still keeping the flexibility to do so when absolutely necessary).

In Quarkus 3.31, we introduced the quarkus packaging, which comes with its own lifecycle. This packaging is intended to be used only for the Quarkus application module itself. It automatically binds the goals of the quarkus-maven-plugin, resulting in less boilerplate in your pom.xml (and no changes required when new goals are added). More importantly, it does not bind the maven-jar-plugin execution, nor the maven-install-plugin, which leads to significantly faster builds for large applications, and benefits all applications overall.

For newly generated applications, this new quarkus packaging will be the default.

Once 3.31 is released, you will also be able to switch your existing applications to the new packaging by applying the following changes:

To give you an idea of the impact, in our sample large application, this change alone reduced the build time from two minutes down to 37 seconds.

In November 2025, I presented part of this work during the first Quarkus community call (see here for more information about our community calls).

Following this presentation, Martin Panzer, one of our regular community contributors, opened an issue in the SmallRye OpenAPI project highlighting how slow the build could be for large applications. He provided a solid reproducer, which enabled Mike Edgar to implement several improvements that significantly reduced the contribution of SmallRye OpenAPI to the overall build time.

These changes will directly benefit Quarkus build times, but since SmallRye OpenAPI is also used by other runtimes, they will positively impact the broader Java ecosystem as well.

The takeaway is simple: when you notice something odd, report it, we might be able to improve it.

In Quarkus, we generate a significant amount of bytecode, and for large applications you need to be careful, as scale can cause our generated bytecode to hit certain limits (for example, method size or class size limits).

The original French article mentioned hitting such a limit at a particular scale. To be fair, that scale was already quite large, but it’s still not ideal to run into an arbitrary limit just because one class happens to push you over the edge.

We recently alleviated this limitation, and Quarkus can now handle much larger applications. This improvement will also be available in Quarkus 3.31.

Recently, we have rewritten most of our bytecode generation to use Gizmo 2, which is built on top of the Class-File API. This work is still ongoing, but key components such as ArC, our CDI implementation, are already relying on it.

To preserve compatibility with Java 17 and 21, we currently use a backport of the Class-File API, but the Class-File API is relying on some classes from the underlying JDK. Several of these classes have seen significant optimizations in Java 25, and as a result, our bytecode generation performance improves noticeably when running on Java 25.

As Quarkus 3.31 will provide full support for Java 25, we recommend using it to build your applications and take advantage of these performance improvements.