fix(build): restore compatibility with JDK11+

[jerrinot]

Fix crash on Java 11+ and module name regression introduced in 1.3.5

Who is affected: anyone using questdb-client 1.3.5 - 1.3.7 on Java 11 or newer, and anyone referencing the client from the module path.

Impact:

• Ingesting certain double values (very large/small exponents) crashes with NoClassDefFoundError: sun/misc/FDBigInteger. Java 8 users are not affected.
• The Java module name accidentally changed from io.questdb.client to questdb.client, breaking module-path consumers on upgrade.

This PR restores the module name and packages the jar so double formatting works on Java 8 and on Java 11 and newer. Java 9 and 10 (long-EOL, non-LTS) remain unsupported, as in every release since 1.3.4.

[jerrinot]

I've verified the full chain. Here's my review.

---

PR #84 Review — fix(build): restore compatibility with JDK11+ (level 0)

Level 0 single-pass review. Level 3 exists for a full 13-agent mission-critical pass — reasonable to consider here since this touches the release/publish pipeline, but the diff is self-contained build config + tests and I was able to verify it end-to-end inline.

Committed-binary gate: PASS. All 6 changed files are text (git diff --numstat shows real line counts, no -/- binary markers). No build artifacts committed.

What this PR is: pure build/packaging + test infrastructure. No production client code changes. It (a) pins Automatic-Module-Name: io.questdb.client + Multi-Release: true in the JDK 8 jar manifest, (b) compiles src/main/java11 into META-INF/versions/11 via antrun on JDK 8 builds, (c) fails the build fast if JAVA11_HOME is absent, (d) refuses to publish from a non-JDK-8 JDK, and (e) adds DoubleFormatSmoke + JarPackagingIT to guard the packaged jar.

Verification performed

• Test efficacy (the load-bearing check). Traced DoubleFormatSmoke's values through Numbers.appendDouble0: the FdBig slow path (Numbers.java:659) is taken when !(bBits < 64 && tenBits < 64). Subnormal/extreme-exponent values (Double.MIN_VALUE, -2.225073858507201E-308, Double.MAX_VALUE, 1.0E-300) push those bit counts ≥ 64 and genuinely reach FdBig → jdk.internal.math.FDBigInteger. Without the versions/11 bridge these throw NoClassDefFoundError: sun/misc/FDBigInteger on Java 9+, so the smoke exits non-zero. The regression test is not vacuous — it reproduces the exact 1.3.5–1.3.7 bug.
• Runtime access. Confirmed Compat.exportFdBigInteger() (pre-existing) reflectively calls Module.implAddExports so the smoke works under plain java -cp with no --add-exports — matching what real classpath consumers get.
• No arch mismatch at release. All three JDK-8 packaging jobs that need it (ci.yml:build-jdk8, release verify, release publish) run on ubuntu-latest (x64) and set JAVA11_HOME: ${{ env.JAVA_HOME_11_X64 }}. The env var name matches setup-java's x64 export. No aarch64/mac packaging job is left without it.
• mvn -pl core test still works without JAVA11_HOME — antrun is bound to prepare-package and failsafe to integration-test, both after test; confirmed matches the CLAUDE.md claim.
• Surefire/failsafe split is correct: **/*IT.class excluded from surefire, failsafe's default **/*IT.java picks up JarPackagingIT, and it's the only *IT file (no pre-existing IT silently disabled).
• Java 9/10 correctly stated as unsupported — versions/11 is not selected by a Java 9/10 runtime, which falls back to the root sun.misc class. Description is honest.

Critical

None.

Moderate

None.

Minor

1. JarPackagingIT.collectJavaSources assumes filename == class name (JarPackagingIT.java:118). It maps each Foo.java → a single META-INF/versions/11/.../Foo.class and asserts that entry exists. It does not verify inner/nested classes (Foo$Inner.class) or a package-private top-level class whose name differs from the file. Harmless for the current FdBig.java/Compat.java (and antrun compiles the whole srcdir, so an outer class can't ship without its inner classes), but the guard is weaker than its comment implies ("every source in src/main/java11 must ship"). If someone later adds a java11 source with a differently-named top-level class the assertion would false-fail. Low priority.

2. runSmokeAgainstJar never closes the child Process streams (JarPackagingIT.java:82). process.getInputStream() is read to EOF (correct order — avoids the pipe deadlock, and redirectErrorStream(true) means no second pipe), but the stream/process isn't closed on any path. Negligible for a short-lived test subprocess; noting for completeness.

3. No Fixes #NNN in the PR body. If there's a tracking issue for the 1.3.5–1.3.7 regression, reference it at the top per CLAUDE.md conventions.

Informational (behavioral change worth surfacing)

• Any JDK 8 mvn package/install/verify now hard-requires JAVA11_HOME, including the parent questdb repo's -P local-client build if it drives this module through packaging on JDK 8. This is intentional (fail-fast beats silently shipping the broken jar) and documented in the CLAUDE.md diff, but downstream/parent-repo builders should be aware.

Summary

Verdict: approve. Well-constructed, correctly-targeted fix with a genuinely efficacious regression test — I verified the test reaches the FdBig path that caused the original crash, and that all release packaging jobs have JAVA11_HOME wired with the correct arch suffix. 0 Critical, 0 Moderate, 3 Minor nits, 1 informational. Draft findings: I checked the two highest-risk hypotheses (vacuous smoke test; release-time arch mismatch leaving JAVA11_HOME empty) and both were disproven. All findings in-diff; cross-context surface is limited (the only production symbols touched by the tests — StringSink.put(double), Compat.exportFdBigInteger, FdBig — are unchanged and verified reachable).

[nwoolmer]

L G T M