OpenJDK JDK

HotSpot VM・Java SEモジュール・compilerを、同じソースツリーで追える

GitHub上のsrcツリーにはhotspot、java.base、java.compilerをはじめ多数のモジュールが含まれています。JVMだけ、標準ライブラリだけ、コンパイラだけを別々のプロジェクトとして見るのではなく、JDKとして一体で変更される境界を確認できるのがこのリポジトリの価値です。Java言語機能、GC/JIT、I/O・network・security・desktopなどの標準API、javacを含む開発ツールの実装を上流で追いたい場合の一次情報になります。

出典：[1][3]

configure → images → tier1 testまで、JDKそのものを再現可能なビルド手順が公開されている

公式build documentationは、source clone後にbash configure、make images、生成したjava -versionの確認、make test-tier1という最短手順を示しています。Linux・macOS・AIX・Windowsをmainlineの対象としており、WindowsではCygwin、MSYS2、WSLなどのPOSIX layerが必要です。JDKの内部変更を自分の環境でbuildし、最低限のtestまで回す導線が明示されています。

出典：[4]

masterがどのJDK世代を作っているかを、version設定から明示的に判定できる

make/conf/version-numbers.confでは、現在のmainlineがDEFAULT_VERSION_FEATURE=28、DEFAULT_PROMOTED_VERSION_PRE=eaであることが定義され、予定日として2027-03-23、class file major version 72、acceptable boot JDKとして26・27・28が設定されています。したがって、このmasterを読むときは「現在配布中の安定版JDK」と同一視せず、JDK 28に向けたEarly-Accessの開発線として扱う必要があります。

出典：[5]

JDK内部の挙動検証、OpenJDKへの貢献、独自buildやdownstream patchを扱う開発者向け

GC/JITやclass library、compilerの挙動を実装レベルで確認したい場合、JDKのbug修正やJEP実装を追いたい場合、vendorや研究用途で独自JDK buildを作りたい場合に向きます。通常のWeb/業務アプリで「Javaを使いたい」だけなら、mainline sourceをbuildするより、用途に合うprebuilt JDK distributionや対象versionのupdate repositoryを利用する方が運用負荷は小さくなります。

mainline masterは安定版配布物ではない。保守対象のJDKでは対応するupdate repositoryを選ぶ

build documentationはjdkを「main-line currently in development」と位置づけ、JDK 17のような過去versionをbuildする場合は、GA時点で凍結されたjdk17ではなく更新を受け続けるjdk17uのようなJDK Updates repositoryを強く推奨しています。productionで特定JDKを保守する目的なら、masterを固定して使うのではなく、そのversionのupdate lineとdistribution方針を先に決める必要があります。

出典：[4][5]

buildは重量級で、boot JDK・native toolchain・disk/RAMまで含めた環境準備が必要

公式文書はJDKをcomplexかつmassiveなprojectとし、SSDを強く推奨しています。x86では最低でも2〜4 cores、2〜4 GB RAM、6 GB以上の空きdisk、AArch64では8 cores、8 GB RAM、6 GB以上のdiskを目安として示しています。さらに現在のJDK 28 mainlineではboot JDKとして26・27・28が許容されます。単一Java libraryのbuildと同じ感覚ではなく、native compilerやbuild toolsを含むtoolchain全体を管理する必要があります。

出典：[4][5]

ライセンスはGPL v2を基礎にClasspath Exceptionを含む。再配布・改変ではfile headerまで確認する

repository metadataはGPL-2.0として認識され、root LICENSEにはGPL version 2とClasspath Exceptionが収録されています。一方でExceptionは「certain source files」に適用されると記載されているため、JDKを改変して再配布する場合やsourceの一部を別製品へ取り込む場合は、単に「Classpath Exception付きだから問題ない」と一般化せず、対象fileのlicense headerとthird-party licenseを確認する必要があります。

出典：[6][5]