Bump google-java-format to 1.27.0 and fmt CI JDK to 17

[Divyansh-db]

Summary

Two-part fix that gets mvn spotless:apply working on the JDK 25 code-generator environment and keeps it ergonomic for contributors whose default JDK is still 11.

1. Upgrade google-java-format and the fmt CI JDK

Follow-up to #777. That PR pinned GJF to 1.22.0 under the assumption it had the JDK 25 fix — it doesn't. GJF 1.22.0 still calls the old Queue-returning Log$DeferredDiagnosticHandler.getDiagnostics() signature that OpenJDK removed in JDK 23+, so the code generator (JDK 25) continued crashing with the same NoSuchMethodError.

• Bump GJF to 1.27.0 in pom.xml — first release with the DeferredDiagnosticHandler API-change fix (Google's commit 96f114c, shipped 2025-05-06).
• Bump fmt CI job to JDK 17 in .github/workflows/push.yml — GJF 1.25.0+ requires JRE 17 to run, so any version that supports JDK 25 forces a JDK floor bump for the one job that invokes spotless. No GJF version supports both JRE 11 and JDK 25.

2. Local-dev ergonomics

Because GJF 1.27.0 needs JRE 17 to load, mvn spotless:apply on a JDK 11 default crashes with UnsupportedClassVersionError. To keep make fmt working transparently for contributors still on JDK 11:

• make fmt-jdk17 — new target, runs JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 mvn spotless:apply.
• make fmt — now falls back to fmt-jdk17 automatically if the default-JDK attempt fails. The first attempt still runs visibly (so a genuine non-JDK error wouldn't be hidden), then a clear ==> Retrying with JDK 17... message before the fallback.

Contributors on JDK 17+ as their default see no behavioral change. Contributors on JDK 11 don't have to learn the new JDK pinning incantation — make fmt just works.

Scope of the JDK bump

Only the fmt job moves. The rest of CI is untouched:

• unit-tests matrix (JDK 8/11/17/20 running mvn test): unaffected. Spotless has no <execution> binding, so mvn test never loads GJF.
• release-build-check.yml / package.yml (JDK 8): unaffected, same reason.
• check-lock job (JDK 11): unaffected.
• Compiled bytecode target stays Java 8 via maven-compiler-plugin.

Test plan

Verified locally against all three JDKs available on the dev machine:

• JDK 17 — JAVA_HOME=.../java-17-openjdk-amd64 mvn spotless:check → BUILD SUCCESS
• JDK 11 — fails with UnsupportedClassVersionError: ... class file version 61.0, this version of the Java Runtime only recognizes class file versions up to 55.0. Intentional floor; no CI job invokes spotless under JDK 11.
• JDK 25 — JAVA_HOME=.../temurin-25-jdk-amd64 bash scripts/mvn-spotless-apply.sh → BUILD SUCCESS (~13s). End-to-end reproduction of the generator's environment.
• make fmt on JDK 11 — first attempt fails as expected, fallback message appears, then JDK 17 path runs and succeeds. Net result: BUILD SUCCESS.
• make fmt-jdk17 directly — BUILD SUCCESS in ~14s on a default-JDK-11 shell.
• genkit update-sdk end-to-end on JDK 11 — succeeds (1325 tests, 0 failures). The local generator workflow is not blocked.
• git diff --stat after running spotless:apply on a clean tree shows no source-file reformats required by GJF 1.27.0 — diff is just config edits.
• CI: fmt (now JDK 17), all unit-tests matrix rows, release-build-check, check-lock all green.

NO_CHANGELOG=true

[github-actions]

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/sdk-java

Inputs:

• PR number: 778
• Commit SHA: 934a8a1ac7ee78dbc8b91a3834303398ab59c3ae

Checks will be approved automatically on success.