ci(build): build and release questdb-client on JDK 8#56
Merged
Conversation
The Maven Central release pipeline compiled, tested, and deployed the artifact on JDK 11 (and built the native libraries on GraalVM JDK 25), while ci.yml already treats JDK 8 as the source of truth. On JDK 11 the java11+ Maven profile auto-activates, producing a Java 11 artifact (class-file v52 -> v55, src/main/java11 shim, logback 1.5.x) that a JDK 8 runtime cannot load -- contradicting the "ships as a Java 8 artifact, released from JDK 8" contract. Move the whole release workflow to JDK 8: - resolve, build-macos, verify, publish, open-bump-pr: setup-java 11 -> 8, so the java8 profile activates and verify/publish build & ship the real Java 8 artifact (source/target 1.8, src/main/java8, logback 1.3.x). - Native builds (linux x86-64/aarch64, windows cross-compile): replace GraalVM JDK 25 with Temurin JDK 8 via the Adoptium latest-GA redirect. The native build only consumes $JAVA_HOME/include JNI headers (core/CMakeLists.txt) and the JNI ABI is stable, so JDK 8 headers are the correct floor. The Windows jni_md.h now comes from openjdk/jdk8u. YAML validated; Adoptium download URLs and the jdk8u jni_md.h path were confirmed to resolve.
bluestreak01
changed the title
GitHub's runner now forces actions/checkout onto Node 24, which needs glibc >= 2.28; the manylinux2014_x86_64 container is glibc 2.17, so the stock /__e/node24 binary aborts with GLIBC_2.27/2.28 not found and the checkout step fails. There is no glibc-2.17 build of Node 24, so reuse the glibc-2.17 Node 20 binary for the node24 path too -- bind-mount /node20217 over /__e/node24 as well. checkout's JS runs fine on it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
We recently moved
java-questdb-clientto a JDK 8 floor — the client ships as the Java 8io.questdb:questdb-clientartifact, andci.ymlalready treats JDK 8 as the source of truth (build-jdk8). But the Maven Central release pipeline (maven_central_release.yml) was still on newer JDKs:resolvebuild-macosbuild-linux-x86-64/aarch64/windowsverifymvn verify— test gatepublishmvn deploy— ships to Centralopen-bump-prThe POMs auto-activate a profile from the running JDK. On JDK 11 the
java11+profile (core/pom.xml) kicks in and changes what gets shipped:javac source/target→ 11 → bytecode is class-file v55, so a JDK 8 runtime hitsUnsupportedClassVersionError.src/main/java11(module-info +jdk.internal.math.FDBigIntegerbridge).So
verifywas testing — andpublishwas shipping — a Java 11 artifact, contradicting the "ships as a Java 8 artifact, released from JDK 8" contract.Change
Move the entire release workflow to JDK 8.
setup-javajobs (5) —resolve,build-macos,verify,publish,open-bump-pr:java-version: "11"→"8". Now thejava8profile activates, soverify/publishbuild and ship the real Java 8 artifact (source/target1.8,src/main/java8shim, logback 1.3.x).Native-lib jobs (3) —
build-linux-x86-64,build-linux-aarch64,build-windows-x86-64: replaceInstall GraalVM JDK 25withInstall Temurin JDK 8via the Adoptium latest-GA redirect (api.adoptium.net/v3/binary/latest/8/ga/<os>/<arch>/jdk/hotspot/normal/eclipse).Why JDK 8 is correct for the native builds
The native build consumes only
$JAVA_HOME/include/jni.h+include/<platform>/jni_md.h(verified incore/CMakeLists.txt, lines 95–128) and produces platform machine code, not Java bytecode. The JNI ABI is stable, so building against JDK 8 headers is fine — and is the most correct choice for a Java 8 floor. The Windows cross-compile'sjni_md.hnow comes fromopenjdk/jdk8u(jdk/src/windows/javavm/export/jni_md.h) instead ofjdk25u; the macros/typedefs are byte-identical.The manylinux containers (glibc 2.17 / 2.28) run Temurin 8 fine, and the install mirrors the prior
wget-tarball pattern (nosetup-java, which needs Node 20 unavailable in the old container).Verification
yaml.safe_load).openjdk/jdk8uWindowsjni_md.hpath resolves and contains the expectedJNICALL/jint/jlongdefinitions.11/25/graalvm/jdk25ureferences in the workflow.Out of scope
rebuild_native_libs.ymlalso uses GraalVM JDK 25, but it's a separate utility workflow, not the release-to-Central path. Happy to align it in a follow-up if wanted.