baredevcontainer/temurin repository overview

⁠temurin

Dev container image for Java development, with the Eclipse Temurin⁠ JDK installed, built on the debian⁠ base image.

Like every image in this repository, it is minimal, built only from upstreams verified at build time, and published with SLSA provenance, a GitHub artifact attestation, and an SBOM; it runs as the non-root user dev. Why these images⁠ explains the reasoning, and Verifying the image⁠ below shows how to check a build.

⁠Image

ghcr.io/bare-devcontainer/temurin:<tag>

Reference it from .devcontainer/devcontainer.json, pinning the digest as well as the tag:

{
  "image": "ghcr.io/bare-devcontainer/temurin:21@sha256:<digest>"
}

⁠Dev Container Template

A ready-to-use Dev Container template for this image is available at bare-devcontainer/templates⁠. It provides the recommended configuration for this image, including security hardening and volume mounts that persist cache directories for faster rebuilds.

⁠Tags

Tags are also published with a date suffix on each build (e.g., 25.0.4.1-trixie-<YYYYMMDD>).

The version in these tags is the version of the JDK, as Temurin numbers its releases (21.0.12.1 is the JDK 21.0.12.1 release); the build number is not part of the tag.

⁠Installed software

Everything from the debian⁠ base image, plus:

• Eclipse Temurin JDK⁠ (java, javac, jar, jshell, keytool, and the other JDK tools), one feature release per tag

JAVA_HOME is /usr/lib/jvm/temurin, a symlink to the installed JDK. The path is the same in every tag and on both architectures, so a devcontainer.json can point a Java extension at the JDK without knowing which one it is running. The JDK's tools are on PATH through Debian's alternatives system. The JDK's trust store is the system CA store, kept in step by adoptium-ca-certificates, so certificates added with update-ca-certificates are trusted by Java as well.

~/.m2/repository and ~/.gradle exist and are owned by dev. Mount a volume on ~/.m2 and on ~/.gradle rather than on the caches inside them: mvnw and gradlew install the build tool a project pins under ~/.m2/wrapper/dists and ~/.gradle/wrapper/dists, so a volume covering only the local repository re-downloads it on every rebuild.

⁠Not installed

• No Maven or Gradle. A project's mvnw or gradlew wrapper downloads the version the project pins, so the image adds nothing that could disagree with it. Add a Dev Container Feature or your own Dockerfile for a project without a wrapper.
• No language server. The Java extensions of VS Code and the JetBrains IDEs bring their own, and only need the JDK this image provides.
• No second JDK. One feature release is installed per tag. The Adoptium apt repository stays configured, so a Dockerfile built on this image can apt-get install temurin-17-jdk next to it; update-alternatives --config java then switches between them.

Unlike the version-manager images, the JDK here is fixed by the image tag. A project that requires a newer feature release than the tag provides needs the matching tag rather than a download at runtime.

⁠Supply chain

The JDK is installed with apt from the Adoptium package repository⁠, the channel Adoptium documents for Debian, pinned in build.yaml to an exact package version. apt verifies the repository index against Adoptium's signing key on every install, and the key (temurin/adoptium-signing-key.asc) is committed to this repository, so the index is checked against a key reviewed here rather than one fetched at build time.

⁠Verifying the image

Every build is published with SLSA provenance, a GitHub artifact attestation, and an SBOM. The attestation confirms that an image was built by the release workflow of this repository and has not been altered since:

gh attestation verify oci://ghcr.io/bare-devcontainer/temurin:<tag>@sha256:<digest> \
  --owner bare-devcontainer

The Docker Hub mirror carries the same digests, so the same command verifies an image pulled from docker.io/baredevcontainer/temurin. Verifying Published Images⁠ covers inspecting the provenance and the SBOM as well.