vasiliy-mikhailov opened a new pull request, #3477: URL: https://github.com/apache/fluss/pull/3477
## 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
