[build] Add JDK 22–27+ support via consolidated jdk22plus profile - #146
Open
stratika wants to merge 7 commits into
Open
[build] Add JDK 22–27+ support via consolidated jdk22plus profile#146stratika wants to merge 7 commits into
stratika wants to merge 7 commits into
Conversation
jdk26 and jdk27 hardcoded the TornadoVM dev artifact version
(5.2.1-jdk26-dev, 5.2.1-jdk27-dev) as literal strings instead of
composing it like jdk21/jdk25 do. Add tornadovm.dev.suffix (-dev)
and have jdk26/jdk27 locally override tornadovm.base.version to
5.2.1, then compose tornadovm.version the same way the other
profiles do: ${tornadovm.base.version}${jdk.version.suffix}${tornadovm.dev.suffix}.
jdk26/jdk27 compose tornadovm.version with tornadovm.dev.suffix (default "-dev") since no GA TornadoVM release exists yet for those JDKs, only locally-built dev artifacts. That property is the actual dependency version for tornado-api/tornado-runtime, so a real `mvn deploy -P release` would otherwise publish a POM depending on an unresolvable *-dev coordinate. Clear it in the release profile, mirroring the existing maven.javadoc.skip/gpg.skip override pattern. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
pom.xml: jdk21/jdk25 composed tornadovm.version without
tornadovm.dev.suffix, unlike jdk26/jdk27. Once tornadovm.base.version
was bumped to 5.2.1 (current TornadoVM dev target; GA not yet
published) this broke default builds on JDK 21/25: they tried to
resolve the bare tornado-api/tornado-runtime:5.2.1-jdk{21,25}
coordinate, which doesn't exist yet (only the "-dev" line does).
Make all four profiles compose tornadovm.version the same way:
${tornadovm.base.version}${jdk.version.suffix}${tornadovm.dev.suffix}.
tornadovm.base.version is now the single knob for "which TornadoVM
tag are we tracking" - testing/default builds get "-dev" appended
(matches a locally-built TornadoVM checkout), and the release profile
strips it to resolve the plain GA coordinate instead. Also drops the
now-redundant per-profile tornadovm.base.version override in
jdk26/jdk27 and refreshes stale profile comments accordingly.
deploy-maven-central.yml: documents (commented out) the jdk26/jdk27
matrix entries to add once TornadoVM's 5.2.1 GA is actually published
for those JDKs - left disabled for now so the release pipeline
doesn't attempt a deploy that's guaranteed to fail on dependency
resolution.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
TornadoVM consolidated its old per-version jdk25/jdk26/jdk27 dev
profiles into a single jdk22plus SDK build that runs unchanged across
JDK 22-27+ (one build, floor-compiled at release 22 - see TornadoVM's
own pom.xml). Mirror that here instead of maintaining three near-
identical profiles that only differed in the revision string:
- jdk21 narrowed to [21,22), now that jdk22plus covers the rest
- jdk25/jdk26/jdk27 replaced by one jdk22plus profile, activation
[22,), suffix -jdk22plus, publishing gpu-llama3:${revision}-jdk22plus
- Drops --enable-preview (FFM, the only reason jdk21 needs it, is final
since JDK 22) via combine.self="override", keeping only add-modules
jdk.incubator.vector - exactly what the former jdk27 profile already
proved compiles clean, now applied across the whole [22,) range
- deploy-maven-central.yml: renamed the jdk25 matrix entry to
jdk22plus (still built on 25.0.2-open, just no longer a jdk25-only
artifact) and dropped the jdk26/jdk27-held-back note - one published
*-jdk22plus artifact now serves that whole range, no separate
matrix entries needed once TornadoVM publishes a 5.2.1 GA release
Verified `./mvnw clean package -DskipTests` on JDK 25 resolves
tornado-api/tornado-runtime:5.2.1-jdk22plus-dev and produces
gpu-llama3-1.0.0-jdk22plus.jar.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
pom.xml collapsed the old per-version jdk25/jdk26/jdk27 profiles into one jdk22plus profile ([22,)). Bring docs and release automation in line: - README.md: Prerequisites bullet, Java badge, and Maven/Gradle dependency snippets now reference jdk21/jdk22plus instead of the removed jdk25 profile. - prepare-release.yml: the README-snippet generator was still hardcoding jdk25/-jdk25, which would have written broken artifact coordinates on the next release since that profile no longer exists. Now generates jdk21/jdk22plus. - build-n-run-engine/SKILL.md, build-tornado/SKILL.md: prerequisite JDK lists updated from "21, 25, or 27" to "21, or 22+ (22-27+)".
orionpapadakis
added a commit
that referenced
this pull request
Aug 28, 2026
…dings The handoff still told the next session to retarget #129, assess #142 and expect three conflicting PRs. All four landed on 2026-08-28, so that guidance would have sent someone to do work that is done — the same failure mode the 2026-08-03 notes had, which this file already warns about. - The pending-PR table becomes a landed table: what each cost to adapt, and which PRs are genuinely still open (#131, #146, #148, and #149 which is this branch). - The merge guidance is gone rather than kept as history. It described a decision — which base to merge into — that has been made and acted on. - Records that CI had been dead for a month, why a green code-quality check hid it, and that build-and-run.yml draws from a pool with both a Mac and a Linux runner, so an unpinned job can pass on one and fail on the other. - Records the CUDA Q8_0 batch-prefill skip and the TornadoVM issue behind it. - Git state: the branch is pushed and open as draft PR #149, its history was rewritten, and force-pushing now needs asking because it is no longer local-only. Immediate next actions now say plainly that M6 cannot start until D-10, D-12 and D-14 close, and lists what is actually actionable meanwhile: the T1.7 recording call, wiring the benchmark gate into CI (only #146 still in the way), and taking the packed-half2 numerics question back to #138. Adds the defects found while landing the four PRs, with what they share: each was invisible because the thing that would have caught it was not running — no golden for that family, no CI, or no test exercising that overload. Architecture link validation: 326 internal links across the docs all resolve.
orionpapadakis
added a commit
that referenced
this pull request
Aug 31, 2026
Written in M1, left unconnected since — it was waiting on #142 (landed) and #146. The performance-gate job measures the pinned CUDA tuple and compares the median eval_rate against the most recent gate-passing entry for that tuple in docs/perf-history.jsonl. Push to main only, matching the guard publish-performance-history already uses: a PR from a fork cannot be trusted with the history, and a gate on unpinned hardware compares against the wrong baseline. It deliberately does not --append. publish-performance-history is what records runs; two writers would race for one file and double-count the same run. The gate reads history and judges, and does not write it. All the gate's exit codes are honoured, including the one that means "do not judge": a regression fails the job, but an unstable environment warns and passes. A machine too noisy to measure has said nothing about the code, and failing there teaches people to ignore the gate. Two shell details that would have made the job lie: GitHub runs `run:` under bash -e, so the gate's own non-zero exit would abort the step before its status could be read — errexit is off around the call — and the status comes from PIPESTATUS[0] rather than $? because the output goes through tee. make test-scripts stays green.
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
1 participant
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.
Summary
Extends GPULlama3.java's JDK support from
{21, 25}to21plus an open-ended22+range (22, 23, 24, 25, 26, 27, and future releases), tracking TornadoVM's own move to a single consolidatedjdk22plusSDK build. Replaces the short-lived per-versionjdk25/jdk26/jdk27Maven profiles with onejdk22plusprofile, fixesllama-tornadoto handle JDK 27's removal of JVMCI, and updates all docs/release automation to match.Why
jdk25/jdk26/jdk27dev builds in favor of onejdk22plusSDK that runs unchanged across the whole range — this repo'spom.xmlhad drifted into three near-duplicate profiles chasing that per-version, which was both unnecessary and left a JDK 26.x activation gap.jdk.internal.vm.cimodule entirely (8382582: Remove the experimental JVMCI feature openjdk/jdk#30834);-XX:+EnableJVMCIbecame a fatal unrecognized VM option and TornadoVM ships a vendoredjdk.internal.vm.cimodule to compensate.llama-tornadoneeded to detect this and branch its JVM flags accordingly instead ofalways assuming JVMCI is present.
Changes
pom.xmljdk25/jdk26/jdk27into onejdk22plusprofile, activation[22,)— closes the JDK 26.x activation gap that existed between the oldjdk25([25.0.2,)) and a since-addedjdk26profile.5.2.1, parameterized viatornadovm.dev.suffix(defaults to-devfor local/CI builds against a dev TornadoVM checkout, stripped to empty in thereleaseprofile so real releases resolve the plain GA coordinate).jdk22plusdrops--enable-preview(FFM is final since JDK 22) and compiles with--add-modules jdk.incubator.vectoronly (Vector API still incubating through at least JDK 27 / JEP 508).llama-tornado$JAVA_HOME/bin/java -version.-XX:+EnableJVMCI/--enable-preview, sets-Djdk.internal.vm.ci.enabled=trueand the--add-exportsneeded by TornadoVM's vendoredjdk.internal.vm.cimodule, and puts that module on the module path.jvmci-21.0.2.jarvia--patch-module, since the platformjdk.vm.ci.*interfaces on those releases have drifted from what the reflection providers were compiled against.tornado.py/tornado --printJavaFlagsalready does, since this script builds its Java invocation independently..github/workflows/deploy-maven-central.ymljdk25/25.0.2-open→jdk22plus/25.0.2-open(one build within the range now covers publishing the wholejdk22plusartifact; noted that GA5.2.1-jdk22plusisn't on Maven Central yet, only the-devline, so this entry will fail resolution until TornadoVM cuts that GA release — samecaveat the prior jdk26/jdk27 note carried).
.github/workflows/prepare-release.ymljdk21/jdk25tojdk21/jdk22plus(was still hardcoding the now-removedjdk25profile, which would have written broken artifact coordinates on the next release).README.md21, 25to21, 22+ (22–27+)/jdk22plus..claude/skills/build-n-run-engine/SKILL.md,.claude/skills/build-tornado/SKILL.md21, 25, or 27to21, or 22+ (22–27+); build step notes updated to describe the consolidatedjdk22plusprofile instead of per-versionjdk25/jdk27.Testing
jdk21profile)jdk22plusprofile,--patch-moduleJVMCI path)jdk22plusprofile, no-JVMCI path)