[neilv-g]

What

Bumps the pinned ghcr.io/devcontainers/features/java:1 entry in .devcontainer/devcontainer-lock.json from 1.8.0 to 1.8.3, which is what the floating java:1 tag currently resolves to. No other features change, and devcontainer.json is unchanged.

Why

The CI build job currently fails for every PR while building the devcontainer (e.g. #2891):

JDK_DISTRO: tem
Version 25 not found. Available versions:

ERROR: Feature "Java (via SDKMAN!)" (ghcr.io/devcontainers/features/java) failed to install!

• devcontainer.json requests Java "version": "25" with "jdkDistro": "tem". The Java feature resolves that against SDKMAN's live candidate list at build time.
• Java feature 1.8.0 (pinned since chore(deps): bump toolchain and dependencies and resolve linter and security breakages #2606) matches candidates with a regex that can't handle build metadata (+N).
• On 2026-10-14, SDKMAN's only Temurin 25 identifier changed from 25.0.4-tem to 25.0.4.1+1-tem (Temurin's jdk-25.0.4.1+1 re-spin). The last green main build (Oct 14, 00:32Z) installed 25.0.4-tem with the same pinned 1.8.0; the next build (chore(deps): increase Dependabot cooldown period to 21 days #2891, 21:50Z) failed.
• Upstream fixed the version matching in 1.8.2 (Fix java version matching devcontainers/features#1714). 1.8.3 also derives the SDKMAN platform when var/platform is missing (Fix Java feature installMaven failure when version="none" (missing var/platform) devcontainers/features#1721).

How

Updated version, resolved, and integrity for the java entry to the 1.8.3 manifest digest (sha256:61a83921…), verified against GHCR as the digest for both java:1.8.3 and java:1.

Testing

Ran each pinned version's install.sh (VERSION=25, JDKDISTRO=tem) in mcr.microsoft.com/devcontainers/base:trixie, the base image of .devcontainer/Dockerfile:

Feature version	Result
1.8.0 (old pin)	Version 25 not found. Available versions: (exit 1), same as CI
1.8.3 (new pin)	Installing: java 25.0.4.1+1-tem … Done! (exit 0)

The build job on this PR is the end-to-end check, since it installs devcontainer features from scratch.

Corrected Assumptions / Learnings

• devcontainer-lock.json takes precedence over floating feature tags: CI installed java 1.8.0 (the locked digest) even though java:1 resolves to 1.8.3.
• The lockfile pins a feature's install script, not what the script installs. With "version": "25", the script still queries SDKMAN at build time, so upstream data changes can break a pinned build, and the pin keeps upstream fixes out until someone bumps it.
• Nothing bumps this lockfile automatically today: Dependabot's devcontainers ecosystem has never opened a devcontainer-feature PR in this repo, and the lockfile hadn't changed since chore(deps): bump toolchain and dependencies and resolve linter and security breakages #2606. Follow-up: check the Dependabot devcontainers job logs, or decide whether to keep the lockfile.
• The build job's cacheFrom image (webstatus-dev-devcontainer-ci-precommit) isn't published by any workflow, so that job always installs features from scratch. The playwright job only passed because its Java layer was cached from the Oct 13 weekly base image, which masked the failure.