Java: make JDK 11 version normalisation in gradle buildless test robust

[redsun82]

java/ql/integration-tests/java/gradle-sample-without-wrapper-or-gradle-buildless normalises the reported java.version down to 11 so the test asserts the JDK feature version without pinning a specific build. The pattern it used, 11\.[0-9]+\.[0-9]+, assumed exactly three dot-separated components.

That assumption broke on macOS runners, which now provide Temurin jdk-11.0.32.1+1:

-  "java_version": "11"
+  "java_version": "11.1"

java.version for that build is 11.0.32.1. Per JEP 322 a version number is $FEATURE.$INTERIM.$UPDATE.$PATCH, so a fourth component appears whenever upstream ships a patch release (11.0.15.1, 11.0.20.1, 11.0.32.1, ...). The old pattern consumed only 11.0.32 and left .1 behind.

Fix

(r'(?P<key>"java_version"\s*:\s*")11(\.[0-9]+)*([-+][^"]*)?"', r'\g<key>11"')

• (\.[0-9]+)* accepts any number of components, so the next JDK bump won't break it.
• ([-+][^"]*)? tolerates a pre-release/build/opt suffix.
• Anchoring on the java_version key and the closing quote keeps the substitution from rewriting version-like text elsewhere in the diagnostics JSON. The old unanchored pattern would happily rewrite 11.0.32 inside a URL or a path; the new one doesn't.

I kept the normalisation rather than adding attributes.java_version to redact next to java_vendor. Redacting is simpler, but this test deliberately uses plain check_diagnostics instead of the java-specific fixture that drops java_version altogether — the visible version is the assertion that use_java_11 actually took effect, which is the point of the test and of the # The version of gradle used doesn't work on java 17 comment above it. Redacting would silently keep passing if the fixture ever stopped selecting a JDK 11.

diagnostics.expected is unchanged.

Validation

I replayed the diagnostics fixture's post-processing (text replacements → parse → redact → sort → dump) over a reconstructed raw diagnostics payload, for both JSON spacings, and compared the result against the checked-in diagnostics.expected:

java.version	old pattern	new pattern
11.0.32	pass	pass
11.0.32.1	fail (11.1)	pass
11.0.20.1	fail (11.1)	pass
11.0.32-ea+9	fail (11-ea+9)	pass

The old pattern reproduces the CI failure exactly; the new one reproduces diagnostics.expected byte for byte. Non-11 versions (17.0.1, 21.0.5, 1.8.0_412) are left untouched, so the test still fails loudly if a different JDK is picked up.

This is the only place under java/ql/integration-tests that normalises a java version.

[Copilot]

Copilot review overview

🟢 Approval recommended

The regex correctly handles representative JDK 11 formats while preserving checks for non-11 versions.

Review tier: Balanced
Findings: None

What changed in this PR

Makes JDK 11 version normalization resilient to variable-length JEP 322 version strings.

Changes:

• Anchors normalization to java_version.
• Supports patch components and build/prerelease suffixes.

File	Description
java/​ql/​integration-tests/​java/​gradle-sample-without-wrapper-or-gradle-buildless/​test.py	Robustly normalizes JDK 11 diagnostics.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[jketema]

There's a few other places that use similar patterns. Should we update the others too?

[redsun82]

Good catch — yes, and I've done so.

In this repo this is the only version-normalising one: the only other replacements use strips a Relevant output line: prefix, so it's unaffected. The two similar ones are in the Java integration tests that live outside this repo, and I've updated them in a companion change.

Worth flagging what turned up there, since it argues for the quoted form. One of them normalised feature version 9 with 9\.[0-9]+\.[0-9]+. Being unanchored, that didn't just miss the extra component — it also rewrote versions that merely end in a match:

input	9\.[0-9]+\.[0-9]+	"9(\.[0-9]+)+"
9.0.1	9	9
9.0.1.1	9.1	9
19.0.1	19	19.0.1
29.0.4	29	29.0.4

So it was silently mangling any unrelated version ending in 9.x.y anywhere in the diagnostics. Anchoring on the surrounding quotes fixes that as a side effect.

[jketema]

LGTM