CodeQL: the Java analysis takes its JDK from the runner image, which moved from Java 17 to 25 with ubuntu-26.04 #188

Summary

The Java job of the CodeQL workflow (.github/workflows/codeql.yml, build-mode: none) models the JDK API on whatever java the runner image puts on PATH. The workflow does not set up a JDK. When ubuntu-latest moved from ubuntu-24.04 to ubuntu-26.04 on 2026-10-19, that java changed from 17 to 25, and code scanning opened a java/deprecated-call alert (100) for JDK APIs deprecated only after Java 11, the version the release is built with (release.yml: 8 on sustaining/5.4.x, 11 otherwise).

The same happened in OpenDJ: OpenIdentityPlatform/OpenDJ#1231.

Where it showed up

The CodeQL java-kotlin job logs on master:

Both logs then say No specific JDK inferred from the project being analysed; using the java on the PATH. Both runs analysed the same commit, a1d3204b98: 44 results before, 45 after.

The alerts on APIs deprecated after Java 11, with the deprecation as JDK 27 declares it:

Cause

With build-mode: none the extractor takes the JDK from the project when it can infer one and from PATH otherwise. It infers nothing here, so the alert set depends on the default JDK of the runner image and changes whenever GitHub moves ubuntu-latest to a newer image.

Proposed fix

First, align the setup with the other projects. build.yml, deploy.yml and release.yml here still use actions/setup-java@v5, while OpenAM, OpenDJ, OpenICF and OpenIDM use v6 in every workflow. The difference comes from Dependabot: those four have a configuration that updates their GitHub Actions, and this repository has none. So move the three workflows to v6 and add a .github/dependabot.yml with the same weekly, grouped github-actions updates labelled ci and dependencies. Dependabot then also brings the other actions here up to date, such as actions/checkout@v6 and actions/cache@v5.

Set up the JDK that the release is built with in the java-kotlin job before Initialize CodeQL. Use the same actions/setup-java parameters as release.yml will have: temurin, 8 on sustaining/5.4.x, 11 otherwise. CodeQL then models the API of that JDK, and the analysis no longer depends on the runner image.

The JDK 11 model does not report these deprecations, but a removal would still show up. If a future JDK removes one of these APIs, compilation fails in the Build matrix (11, 17, 21, 25 and 27) as soon as that JDK is added to it.