[build] CI build test on Java 17 and 21 (#203 Phase 3)

[vasiliy-mikhailov]

Purpose

Phase 3 of #203: CI build-test coverage for Java 17 and Java 21 (default and release stay Java 11; no target.java.version is changed). As @wuchong noted when closing #114, building on 17/21 largely works already — this PR adds the missing CI coverage from the Phase-3 checklist, plus the two test-level fixes that running the suite on 17/21 surfaces.

Changes

• pom.xml: add --add-exports=java.rmi/sun.rmi.registry=ALL-UNNAMED to the existing extraJavaTestArgs block — JMXServer$JmxRegistry extends the JDK-internal sun.rmi.registry.RegistryImpl, which JDK 17+ strong encapsulation rejects (IllegalAccessError: superclass access check failed; JDK 8/11 only warn). Without it the whole fluss-server suite errors on 17/21. Harmless on 8/11 thanks to the existing -XX:+IgnoreUnrecognizedVMOptions.
• fluss-lake/fluss-lake-hudi/pom.xml: add org.apache.hadoop:hadoop-client-runtime at test scope — Hudi's Flink bundle references hadoop-client-api shaded classes (org.apache.hadoop.shaded.com.ctc.wstx.*); without the runtime jar HudiLakeCatalogTest can fail with NoClassDefFoundError depending on which StAX provider wins. Verified green on 11 and 21 with the dependency.
• ci.yaml: add compile-on-jdk17 / compile-on-jdk21 (compile-only, mirroring compile-on-jdk8) so every PR proves the build on 17/21 cheaply.
• nightly.yaml: add full build-on-jdk17 / build-on-jdk21 test runs via ci-template.

Spotless

The 17/21 jobs pass -Dspotless.check.skip=true, following the precedent #204 established for the Java 8 leg: google-java-format 1.15.0 cannot run on JDK 21 (JCTree$JCImport.getQualifiedIdentifier NoSuchMethodError), and gjf versions that support 21 require a Java 17 runtime — no gjf version spans 11 and 21, so the format check stays on the default-JDK jobs until Phase 4.

A linkage hazard worth a maintainer decision (not changed here)

The build uses maven.compiler.source/target, not release. Compiling on JDK 17/21 therefore links against newer JDK APIs even with target 11 — we reproduced jars built on 21 crashing on a Java 11 runtime with NoSuchMethodError: java.nio.MappedByteBuffer.duplicate() (covariant override added in JDK 13). If artifacts may ever be built on 17/21, maven.compiler.release=11 is the fix; we left it out because it interacts with the java8 profile (javac 8 has no --release) and deserves your preferred treatment.

Verification (local, Temurin 11/17/21)

• mvn -T 1C clean install -DskipTests: green on 11, 17 (both pristine) and 21 (with the spotless skip).
• Full-reactor mvn test on 17 and 21: identical outcomes to the Java 11 baseline run, with fluss-server (1048 tests) green on all three after the --add-exports fix, and HudiLakeCatalogTest green on 11/21 after the dependency fix.
• Pre-existing, JDK-independent: fluss-fs-hdfs fails test discovery identically on 11/17/21 under a plain mvn test (it needs the staged -Ptest-* invocation); fluss-spark-ut's 2-minute lake-sync waits time out under our shared-load environment — the added nightly jobs on clean runners are the right adjudicator for it.