OpenJDK JDK

Follow HotSpot, Java SE modules, and compiler implementation in one source tree

The repository's src tree includes hotspot, java.base, java.compiler, and many other modules. That makes it possible to inspect changes at the boundaries of the VM, core libraries, compiler infrastructure, and JDK tools instead of treating each piece as an unrelated project. It is primary-source material for following Java language implementation, GC/JIT work, standard APIs, security/networking/desktop modules, and compiler behavior.

Sources: [1][3]

The project documents a reproducible path from configure to a built JDK and tier-1 tests

The official build guide gives a short path of bash configure, make images, verifying the generated java -version, and running make test-tier1. Mainline supports Linux, macOS, AIX, and Windows, with Windows requiring a POSIX compatibility layer such as Cygwin, MSYS2, or WSL. This makes local JDK implementation changes buildable and testable rather than leaving the repository as reference-only source.

Sources: [4]

Version configuration makes the active mainline target explicit

make/conf/version-numbers.conf currently sets DEFAULT_VERSION_FEATURE=28 and DEFAULT_PROMOTED_VERSION_PRE=ea, with a target date of 2027-03-23, class-file major version 72, and accepted boot JDK versions 26, 27, and 28. That metadata is important when interpreting master: it is a JDK 28 Early-Access development line, not the same thing as the currently deployed stable JDK on a production system.

Sources: [5]

Best suited to JDK internals work, OpenJDK contribution, custom builds, and downstream patching

It fits engineers who need implementation-level answers about the VM, class libraries, or compiler; contributors following JDK bugs and feature work; and vendors or researchers building their own JDK images. Application teams that only need a Java runtime generally have a lower-operational-cost path through a prebuilt JDK distribution and the update line for their selected Java version.

Master is a development line, not a stable maintenance branch

The build documentation describes jdk as the main line currently in development. For older versions such as JDK 17, it strongly recommends an Updates repository such as jdk17u rather than the GA repository frozen at release. Production maintenance therefore needs an explicit version/update policy instead of treating master as a generic source for every JDK release.

Sources: [4][5]

Building the JDK is substantially heavier than building a normal Java library

The official guide calls the JDK a complex and massive project and strongly recommends SSD storage. It lists at least 2–4 cores, 2–4 GB RAM, and 6 GB free disk for x86, and 8 cores, 8 GB RAM, and 6 GB disk for AArch64. The current JDK 28 mainline also expects a boot JDK from versions 26, 27, or 28. Native compilers and other build dependencies are part of the toolchain.

Sources: [4][5]

GPL v2 and the Classpath Exception require license-aware redistribution

GitHub detects the repository as GPL-2.0, while the root LICENSE includes the GPL v2 text and the Classpath Exception. The exception is described as applying to certain source files, so modified redistribution or reuse of implementation source should verify the headers of the exact files involved and applicable third-party notices rather than assuming a single permissive rule across every file.

Sources: [6][5]