adoptium/temurin-build: the shell layer that turns an OpenJDK source tree into a Temurin binary

A build farm's shell layer, pointed at your own machine

adoptium/temurin-build holds the code and instructions for producing OpenJDK binaries, with Eclipse Temurin as the default target. The scripts can build OpenJDK anywhere, but their real job is to serve the Adoptium members who are vendors, running the same pipeline on the build farm at ci.adoptium.net and publishing what comes out through adoptium.net and the Adoptium API. That framing matters when you read the rest of the repository, because the entry point was written for a repeatable, unattended machine rather than for a curious developer on a laptop.

The repository is a Shell project under Apache-2.0, and its shape follows from that job. There is a `build-farm` folder of multi configuration Jenkins job scripts, a `docker` folder for generating container definitions, an `sbin` folder that does the actual building, a `security` folder holding the certificate bundle, plus top level scripts including `configureBuild.sh`, `sign.sh`, `native-build.sh` and `docker-build.sh`. A `cyclonedx-lib` directory and a `--create-sbom` option show that the pipeline produces a CycloneDX bill of materials, which matters for supply chain review rather than for compilation.

makejdk-any-platform.sh picks the version, variant and boot JDK

Everything a builder touches starts with `makejdk-any-platform.sh`, and the calling convention is short enough to read at a glance. The version argument selects a source repository: `jdk8u` builds Java 8 from the adoptium/jdk8u repository, `jdk11u` builds Java 11, `jdk16u` builds Java 16, and `jdk` means the latest Alpha or Beta source. The variant is chosen with `--build-variant`, with `hotspot` as the default because it draws from the same repositories Temurin itself uses. Other accepted names are `openj9`, `corretto`, `SapMachine`, `dragonwell` and `bisheng`.

The `-J` flag is the one detail that catches newcomers. It names the boot JDK, which should generally be one major version behind the version you are building, though a boot JDK of the same major version also works. The documented call looks like this:

./makejdk-any-platform.sh -J /usr/lib/jvm/jdk-10.0.2 --build-variant hotspot jdk11u

Other flags pass through to the OpenJDK build itself, including `-b` for a custom branch, `-B` for a build number, `-C` for custom configure arguments, and `-d` for the destination path of the resulting binary. The script detects platform and architecture on its own and downloads and installs dependencies such as the ALSA sound and Freetype font libraries locally.

Docker and Podman paths skip the host toolchain entirely

If your machine lacks the compiler and supporting packages that an OpenJDK build needs, the same entry point can run the work inside a container. The `docker` directory contains a generator that turns a variant plus a version into a valid Dockerfile, and the top level script drives it. The documented forms are:

./makejdk-any-platform.sh --docker --clean-docker-build jdk8u
./makejdk-any-platform.sh --podman --clean-docker-build --build-variant openj9 jdk11u

`--clean-docker-build` removes the existing container and persistent volume before a new build starts, which is the difference between a clean result and a stale layer being reused. The `--podman` flag is accepted alongside `--docker` and `-D`.

There is a caveat about the container route that the project's own wording makes plain: the parameter combination only works for versions the generator can produce a valid Dockerfile for. The project also states that these Dockerfiles are tested on a regular basis in the DockerfileCheck job at ci.adoptium.net, so container support is a tracked surface rather than an experiment. For the required host packages on Ubuntu, the dockerfile generator is the place the project points you to, since it enumerates them.

sbin/build.sh is where the compilation actually happens

The layering is worth understanding because it explains why there are so many scripts. `makejdk-any-platform.sh` is the entry point, and it hands off to `native-build.sh` for a host build or `docker-build.sh` for a container build. Both of those in turn call `build.sh` inside the `sbin` folder, which is the part that actually builds Temurin. The project states that `build.sh` can be used stand alone, so it is the lowest layer you can drive yourself if you have already arranged the environment.

Most of the tunables in the script set are passed through to the `configure` and `make` commands that OpenJDK uses, and the project directs you to the `README-builds.html` file inside the OpenJDK source repository you are building for the authoritative list of configuration options. The top level repository also carries `sign.sh`, `entitlements.plist` and `serverTimestamp.properties`, so the pipeline covers signing and timestamp stamping as well as compilation.

The alternative to this repository is the plain OpenJDK source build, driven by `configure` and `make` from the upstream README. The difference is scope: upstream gives you the compiler invocation, while temurin-build adds platform detection, automatic dependency fetching, container generation, variant selection, SBOM output and the signing steps, all in the order the build farm uses.

The cacerts bundle in security/ decides whether SSL works

One folder is worth singling out because it is easy to overlook and expensive to get wrong. The `security` folder contains a script and a `cacerts` file that are bundled with the JDK during the build. The project describes this file as important, since it is what enables SSL connections. In other words, the trust material shipped inside the resulting binary is a build input that this repository controls, not something picked up from whatever the build host happens to have installed.

That is the whole of the security folder's stated role, and it is a narrower claim than a full security story. There is no signing key, no attestation and no vulnerability scanning described for the binaries themselves. A separate top level `sign.sh` handles signing, and the `--create-sbom` option emits a CycloneDX JSON artifact that lists what went into the build, but neither of those replaces a policy for verifying what a published binary contains.

Half the tooling now lives in two other repositories

A first time visitor who navigates the tree looking for the pipeline definitions will not find them. The `git-hg` folder has been moved to its own separate repository, openjdk-mirror-scripts under the adoptium organisation, which holds the scripts formerly kept in the `git-hg` folder. The `pipelines` folder has likewise moved to a separate repository, adoptium/ci-jenkins-pipelines.

That leaves this repository focused on the build scripts themselves, with the continuous integration wiring and the source mirroring handled elsewhere. It also means the upgrade story is spread across three codebases. A change to a mirror script, a pipeline definition and a build script can land in different repositories and different cycles, and the version tags here do not line up with what you might expect: the most recent release tags visible in this repository are v2023.01.03, v2023.01.02 and v2023.01.01 from January 2023, while the last push to the repository was on 2026-10-19. The repository is not archived, and ongoing work lands on the default branch rather than being cut into a new tag each time.

What the documentation leaves open

The help output is the most practical gap. The project points to `makejdk-any-platform.sh --help` and also ships `makejdk-any-platform.1`, so the full option list is available. The repository ships `makejdk-any-platform.1`, so the complete man page sits alongside the script for reference.

Other questions go unanswered. There is no documented rollback for a half finished build, no description of how a failed native build cleans up the locally installed dependencies it fetched, and no statement about which variants are validated on which platforms beyond the container checks. Whether an unsupported variant combination is refused early or fails deep into a configure run is not spelled out. The build farm's Jenkins jobs in `build-farm` are also aimed at operators of that farm, so for a standalone build the local scripts are the only practical starting point.

Editorial conclusion

Adopt temurin-build if you are a vendor or a platform team that must produce signed, reproducible OpenJDK binaries and want the same script chain the Adoptium build farm uses; skip it if you only need a working JDK, because a distribution package or a prebuilt Temurin download will serve you with far less work. Before you commit, verify the exact `--build-variant` and version target your release line expects, confirm that a boot JDK one major version behind the target is present, and check that the build host has the toolchain packages listed in the dockerfile generator, even though the scripts download and install many required dependencies locally.

Frequently asked questions

Official sources

1. adoptium/temurin-build on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases