CI Java Version Drift - "wrong default-jdk" After setup-java - Fix Pin

By Daniel Zoghalchali·Latchkey

The JDK you set up early is not the one running your build, because a later step changed the active Java - a sdkman/jenv shim, a tool that re-exports JAVA_HOME, or a matrix value that did not apply. The active JDK drifted.

What this error means

A build that should use the pinned JDK behaves like a different version - a version-specific compile/runtime error, or java -version printing an unexpected JDK at the failing step despite an earlier setup-java.

CI log

# Step A:
$ java -version  -> openjdk 21
# Step C (after a tool changed JAVA_HOME):
$ java -version  -> openjdk 11   # drifted

Common causes

A later step re-points JAVA_HOME/PATH

Tools like sdkman, jenv, asdf, or a vendored script can export a different JAVA_HOME or prepend a shim to PATH, overriding setup-java.

Matrix or cache restored a different JDK

A matrix axis that did not pin correctly, or a restored cache with a baked JAVA_HOME, leaves a JDK other than intended active.

How to fix it

Re-assert the JDK right before the build

Print and pin JAVA_HOME immediately before each tool invocation so drift is caught and corrected.

.github/workflows/ci.yml

- run: |
    echo "JAVA_HOME=$JAVA_HOME"
    java -version
    "$JAVA_HOME/bin/java" -version   # the one your tools should use

Pin the compile JDK via toolchains

Decouple the build from the ambient JDK so drift in JAVA_HOME cannot change the compile target.

build.gradle.kts

// build.gradle.kts
java { toolchain { languageVersion = JavaLanguageVersion.of(21) } }

How to prevent it

Assert java -version/$JAVA_HOME immediately before each build tool.
Avoid JDK-switching shims (sdkman/jenv) in CI, or pin them explicitly.
Use toolchains so the compile JDK is independent of ambient JAVA_HOME.

Frequently asked questions

What causes "Java version drift in CI"?