より高速なビルドに向けて

ビルドプロセスの様々な部分を最適化するために多大な努力が注がれました。メモリー割り当ての削減、アルゴリズムとデータ構造の最適化がその大きな部分を占めていました。

この作業により、Quarkus、Jandex、さらにはByteBuddyにわたる多数のプルリクエストが生まれました。

私たちのビルドプロセスは既に大規模に並列化されていますが、Hibernate ORMプロキシの生成など、並列化されていなかったいくつかの領域を特定しました。私たちはそれを修正しました。

もう一つの改善点は、大規模なJARアーカイブの作成でした。これは、大量のリソースを読み取り、圧縮することを含むため、本質的に低速であり、I/OとCPUの両方を大量に消費します。これまで、私たちはZipFileSystemを使用して、シングルスレッドでリソースを一つずつ追加しながらJARを構築していました。それ以来、Commons Compressが提供する並列圧縮サポートを使用するように切り替えました。

この変更には、JARアセンブリコードのかなりの大規模なリファクタリングが必要でしたが、それだけの価値は十分にありました。

これらすべての最適化により、quarkus-maven-plugin の様々なゴールに費やされる時間は、参照バージョン3.25.1と比較して半分に短縮されました。 これは素晴らしいことですが、サンプルアプリケーションのビルドには依然として約2分かかり、これは望ましい時間よりも長いです。

一歩引いて、全体像を見る時が来ました。

Quarkusアプリケーションの場合、主に次の2つの理由で独自のJARを構築します。

これは、Commons Compressが提供する並列圧縮サポートを活用することで最適化したプロセスです。

しかし、Mavenを使用する場合、Quarkusアプリケーションは依然として従来の jar Mavenプロジェクトです。これは jar パッケージングの標準ライフサイクルに従うため、Mavenは maven-jar-plugin を使用して従来のJARもビルドします。

一歩引いて考えると、実際にはこのJARは99%のケースで必要ありません。したがって、構築を避けるべきです（ただし、絶対に必要な場合はその柔軟性を維持します）。

Quarkus 3.31では、独自のライフサイクルを持つ quarkus パッケージングを導入しました。このパッケージングは、Quarkusアプリケーションモジュール自体にのみ使用されることを意図しています。これにより、quarkus-maven-plugin のゴールが自動的にバインドされ、pom.xml のボイラープレートが減り（新しいゴールが追加されても変更は不要）、さらに重要なことに、maven-jar-plugin の実行も maven-install-plugin もバインドされません。これにより、大規模なアプリケーションのビルドが大幅に高速化され、すべてのアプリケーションに全体的なメリットをもたらします。

新しく生成されるアプリケーションでは、この新しい quarkus パッケージングがデフォルトになります。

3.31がリリースされたら、既存のアプリケーションを新しいパッケージングに切り替えるために、以下の変更を適用することもできます。

その影響のアイデアを示すと、私たちのサンプル大規模アプリケーションでは、この変更だけでビルド時間が2分から37秒に短縮されました。

2025年11月、私は最初のQuarkusコミュニティコールでこの作業の一部を発表しました（コミュニティコールの詳細については こちら を参照してください）。

このプレゼンテーションに続いて、私たちの常連コミュニティ貢献者の一人であるMartin Panzer氏が、大規模アプリケーションのビルドがいかに遅くなるかを示す SmallRye OpenAPIプロジェクトの課題 を提起しました。彼は堅牢な再現手順を提供し、これによりMike Edgar氏が、SmallRye OpenAPIが全体のビルド時間にもたらす貢献を大幅に削減するいくつかの改善を実装することができました。

これらの変更はQuarkusのビルド時間に直接的な利益をもたらしますが、SmallRye OpenAPIは他のランタイムでも使用されているため、より広範なJavaエコシステムにも良い影響を与えるでしょう。

要点はシンプルです。何かおかしいことに気づいたら報告してください。私たちはそれを改善できるかもしれません。

Quarkusでは、かなりの量のバイトコードを生成します。大規模なアプリケーションでは注意が必要で、規模が大きくなると、生成されたバイトコードが特定の制限（例えば、メソッドサイズやクラスサイズの制限）に達する可能性があります。

元のフランス語の記事では、特定の規模でこのような制限に達したことが述べられていました。公平に言えば、その規模はすでにかなり大きいものでしたが、あるクラスがたまたま限界を超えたというだけで、任意の制限に遭遇するのは理想的ではありません。

私たちは最近この制限を緩和し、Quarkusはより大規模なアプリケーションを扱えるようになりました。この改善もQuarkus 3.31で利用可能になります。

最近、私たちはバイトコード生成のほとんどを、Class-File API を基盤とする Gizmo 2 を使用するように書き換えました。この作業はまだ進行中ですが、当社の CDI 実装である ArC などの主要コンポーネントはすでにこれに依存しています。

Java 17 と 21 との互換性を維持するため、現在は Class-File API のバックポートを使用していますが、Class-File API は基盤となる JDK の一部のクラスに依存しています。これらのクラスのいくつかは Java 25 で大幅な最適化が施されており、その結果、Java 25 で実行するとバイトコード生成のパフォーマンスが著しく向上します。

Quarkus 3.31 は Java 25 の完全なサポートを提供する予定であるため、これらのパフォーマンス向上を活用し、アプリケーションのビルドにこれを使用することをお勧めします。