[#1231] Set up the JDK of the release for the CodeQL Java analysis, so that its results no longer follow the default JDK of the runner image (#1232)
Fixes #1231
### Problem
The java-kotlin job of the CodeQL workflow runs with `build-mode: none`
and sets up no JDK. CodeQL infers no JDK from the project (`No specific
JDK inferred from the project being analysed; using the java on the
PATH`), so it models the JDK API on the default `java` of the runner
image. On 2026-10-19 `ubuntu-latest` moved from ubuntu-24.04 to
ubuntu-26.04, and that `java` changed from 17 to 25. Without a change to
the code, code scanning opened 20 `java/deprecated-call` alerts
(1318–1337) for APIs deprecated in Java 18–21, so only after Java 11,
the version the release is built with. The details are in #1231.
### Fix
- Before `Initialize CodeQL`, the java-kotlin job sets up the JDK that
the release is built with. It uses the `release.yml` setup: temurin, 8
on `sustaining/4.10.x` and 11 otherwise, with the same
`actions/setup-java` version (v6.1.0). CodeQL then models the API of the
JDK the release is built with, and the alert set no longer changes when
GitHub moves `ubuntu-latest` to a newer image. The branch is taken from
`github.base_ref` for a pull request and from `github.ref_name` for a
push.
- The new step pins `actions/setup-java` to the commit SHA of v6.1.0,
like every other action in these workflows. `build.yml`, `deploy.yml`
and `release.yml` pin the same SHA since #1234, so every workflow sets
up its JDK with the same version.
- `github/codeql-action` moves from v4.39.0, the pin of #1234, to
v4.39.1, its newest release, in `codeql.yml`, `build.yml` and
`docker-scan.yml`, also pinned to a commit SHA. It brings the CodeQL
bundle 2.27.3 instead of 2.27.2.
- The commented-out copy of the same step in the Java manual build
section is removed. If that build is turned on, the new step serves it.
The other languages (actions, ruby, c-cpp) do not use the step.
The JDK 11 model does not report these deprecations, but a removal would
still show up. If a future JDK removes `Subject.doAs`,
`Runtime.runFinalization` or
`JMXConnector.getMBeanServerConnection(Subject)`, the Build matrix fails
to compile once that JDK is added.
### Test
The change to `codeql.yml` only takes effect in a CodeQL run, so the
CodeQL run of this PR is the test. The java-kotlin job log must show
`Java version: 11...` for the temurin JDK that setup-java installs,
where master shows `Java version: 25.0.4.1`. The first revision of this
PR, with zulu 11, showed `Java version: 11.0.32, vendor: Azul Systems,
Inc.` in [run
39757355544](https://github.com/OpenIdentityPlatform/OpenDJ/actions/runs/39757355544).
The Build run of this PR runs `codeql-action/upload-sarif` v4.39.1 in
the Trivy step of `docker-test`. `docker-scan.yml` only runs on its
weekly schedule and by hand, so it first runs v4.39.1 after the merge.
A pull request analysis only reports results on the changed lines
(`pr-diff-range`), so it cannot show the 20 alerts going away. They are
closed by the first analysis of master after the merge. The master
analysis of `de42bdce8f` has 368 results. That analysis also moves to
the CodeQL bundle 2.27.3, so it may open or close alerts that have
nothing to do with the JDK.
