I can reproduce the problem with openjdk 17 and 21, with the difference that I’m using ssh to connect to the agent.
I don’t think that this is a Jenkins specific problem but more a problem with openjdk in alpine that is using musl. I can see an environment variable injected
LD_LIBRARY_PATH=/opt/jre17/lib/server:/opt/sapmachine-jdk-21.0.2/lib:/opt/sapmachine-jdk-21.0.2/../lib
which probably comes from the jdk as it is already in the env of the java process itself.
When connecting an agent via ssh, the current environment is printed before starting the Java process, there LD_LIBRARY_PATH is not listed. But when looking that the environment of the agent java process by going to System information of the agent, the it is listed with above values.
I guess that this causes an interception of all calls to processes with name java so that they get replaced by the corresponding java17 executable.
Unsetting the env variable with
unset LD_LIBRARY_PATH in a sh step before calling java -version solves the problem.
Unfortunately it is not possible to set empty variables in the env variables section of a node, but you could set it to a dummy value there.
Toolchain feature detects Java 8 JDK as a different Java version when inside an Alpine Linux container. · Issue #24300 · gradle/gradle · GitHub reports the same issue for gradle