Repository navigation
Migrate build tooling to Java 25 bytecode target and Gradle 9 - #3
Merged
Merged
Conversation
3 of 4 tasks
Pins sourceCompatibility/targetCompatibility to Java 17 (unset before,
defaulting to whatever JDK ran Gradle) so the SDK jar loads on every
nuclio Java runtime image, including the armhf one capped at JDK 17.
Adds a Gradle 9.7.1 wrapper (none existed), drops the ancient
junit-platform-gradle-plugin in favor of Gradle's native
`test { useJUnitPlatform() }`, adds the junit-platform-launcher
dependency Gradle 9 requires explicitly, and moves archivesBaseName
into the Gradle-9-compatible `base {}` block. Replaces the dead
Travis CI config with a GitHub Actions matrix testing JDK 17 and 25.
Version stays at 1.2.0 (set by the prior commit) rather than bumping
further - 1.2.0 was never actually published to Maven Central, so
there's nothing to skip past.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
nuclio's Java runtime now drops armhf (32-bit ARM) support entirely rather than pinning to JDK 17 indefinitely for that one architecture, so the SDK no longer needs a lowest-common-denominator bytecode target. Targets Java 25 via a Gradle toolchain (auto-provisions a JDK 25 compiler regardless of the host's installed default JDK, via the foojay resolver in the new settings.gradle) rather than a plain sourceCompatibility/targetCompatibility pin. CI matrix drops JDK 17 - compiling for release 25 requires the build's own JVM to be JDK 25+. Version stays at 1.2.0 rather than bumping further - 1.2.0 (set by the prior bump-java commit) was never actually published to Maven Central, so there's nothing to skip past. Verified: real ./gradlew build under Gradle 9.7.1, auto-downloaded JDK 25 toolchain, compiled class files confirmed at major version 69 (Java 25) via that JDK's own javap. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rokatyy
force-pushed
the
feature/java25-lts-migration
branch
from
September 21, 2026 11:12
4b4c85f to
46a2b19
Compare
rokatyy
marked this pull request as ready for review
September 24, 2026 12:00
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Unconditional POM signing and the unversioned launcher dependency can break publishing and dependency resolution.
Get a fresh assessment by requesting another Copilot review.
Review effort: Lite
Findings: 1
Open (2)
What changed in this PR
Migrates the Java SDK build to Gradle 9.7.1 and Java 25 bytecode, with updated CI, publishing, testing, and documentation.
Changes:
- Adds Foojay-managed Java 25 toolchain support.
- Modernizes Gradle, JUnit, signing, and publishing configuration.
- Replaces Travis CI with GitHub Actions and updates README guidance.
| File | Summary |
|---|---|
settings.gradle |
Configures Foojay toolchain resolution. |
README.md |
Updates dependency and Java documentation; the 1.2.0 link is unpublished, and local JDK requirements are misstated. |
gradlew.bat |
Adds the Windows Gradle wrapper script. |
gradlew |
Adds the POSIX Gradle wrapper script. |
gradle/wrapper/gradle-wrapper.properties |
Pins Gradle 9.7.1. |
build.gradle |
Updates Java, testing, publishing, and signing configuration. POM signing remains unconditional, and the launcher dependency lacks a version. |
.travis.yml |
Removes obsolete Travis CI configuration. |
.github/workflows/test.yaml |
Adds Java 25 GitHub Actions CI. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
shinil35
approved these changes
Sep 24, 2026
The old OSSRH endpoint (oss.sonatype.org) shut down on 2025-06-30, and the hand-written signing setup only attached pom.asc, broke publishToMavenLocal when signing wasn't configured, and guarded useGpgCmd() on keyring properties. Switch to com.vanniktech.maven.publish, which uploads through the Central Portal, generates sources/javadoc jars, and signs every artifact including the POM. Signing is required only for Maven Central tasks. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
TomerShor
approved these changes
Oct 15, 2026
Comment on lines
96
to
98
| developer { | ||
| name = 'Miki Tebeka' | ||
| } |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
rokatyy
added a commit
to nuclio/nuclio
that referenced
this pull request
Oct 29, 2026
### 📝 Description Migrates the Java function runtime from JDK 11 (the deprecated `openjdk` Docker Hub image) to **Java 25 LTS** via `eclipse-temurin`, its maintained successor, pulled directly from Docker Hub. **Java runtime support for armhf (32-bit ARM) is dropped entirely** — no upstream `eclipse-temurin` build exists for Java 25 on that architecture, and rather than pin that one runtime to JDK 17 indefinitely, this drops armhf Java support outright. Stacked on #4366 ([CI] Migrate base images from gcr.io/iguazio to Docker Hub) — that PR explicitly called out this branch and asked whichever merges second to apply the same treatment. #4366 also reverted `openjdk`/`uhttpc`/the .NET runtime back to `gcr.io/iguazio` because those exact paths don't resolve on Docker Hub — but `eclipse-temurin` is a different, actively maintained image and **does** resolve on Docker Hub (verified locally, see Testing below), so this PR uses the plain Docker Hub reference rather than following that same carve-out. No GCR mirror needed. --- ### 🛠️ Changes Made - Base images → `eclipse-temurin:25-*-noble` (amd64/arm64), pulled directly from Docker Hub, in `Makefile` and `pkg/platformconfig/platformconfig.go`. - armhf: `handler-builder-java-onbuild` now fails fast with `$(error ...)` and a clear message instead of a cryptic image-pull error. - Onbuild image's Gradle bumped to **9.7.1** (required to run Gradle on a JDK 25 JVM). - Shadow plugin `com.github.johnrengelman.shadow` (archived) → its maintained successor `com.gradleup.shadow` (Gradle 9 requirement) — in the wrapper's own `build.gradle`, the Go template that generates every user function's `build.gradle`, and the `custom-gradle-script` test fixture, so wrapper and user-function builds stay in sync. - Dropped the now-moot Debian-bullseye-EOL snapshot-pinning workaround (base image is Ubuntu noble now). - Updated `docs/reference/runtimes/java/java-reference.md` and `doc.go` (Java 25, armhf unsupported). --- ### ✅ Checklist - [x] I updated the documentation (if applicable) - [x] I have tested the changes in this PR --- ### 🧪 Testing - `go build` / `go test -tags=test_unit -race -short` / `gofmt` clean on all touched packages, rebased on top of #4366's tip. - Built the real `handler-builder-java-onbuild` image directly against `docker.io/eclipse-temurin:25-jdk-noble` — resolves and builds cleanly. - Ran `compileJava` and the wrapper's `shadowJar` task inside the built image — `com.gradleup.shadow` produced a working fat jar under Gradle 9.7.1. - `make -n handler-builder-java-onbuild NUCLIO_ARCH=armhf` confirmed to fail with the new explicit error message; unaffected for amd64/arm64. - CI is currently running with a temporary test-only commit that builds the SDK from nuclio-sdk-java#3's branch instead of Maven Central, to exercise the in-flight SDK migration end-to-end — see PR comments. Will be reverted before merge. - Not yet run: full deploy-and-invoke test against a real cluster. --- ### 🔗 References - Ticket link: n/a (proactive maintenance, not ticket-driven) - Design docs links: n/a - External links: stacked on #4366; companion PR — `nuclio-sdk-java` (Java 25 bytecode target + Gradle 9, armhf floor dropped too): nuclio/nuclio-sdk-java#3 --- ### 🚨 Breaking Changes? - [x] Yes (explain below) - [ ] No 1. Any function with a custom `build.gradle` that pins `com.github.johnrengelman.shadow` directly must switch to `com.gradleup.shadow` (documented in `java-reference.md`). Plugin IDs are drop-in compatible — same `shadowJar` task and config block. 2. Java functions can no longer be built/deployed for armhf (32-bit ARM). --- ### 🔍️ Additional Notes - The onbuild Dockerfile's SDK jar pin stays at `nuclio-sdk-java-1.1.0` for now — old bytecode still loads fine on the new JVMs, so this isn't a blocker. Bumping it can follow once the companion `nuclio-sdk-java` PR is republished to Maven Central. - Known non-blocking follow-up: a few Gradle-10-forward deprecation warnings surfaced in `nuclio-sdk-java`'s build (out of scope for this repo). --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
3 of 4 tasks
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
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
Companion to the nuclio Java runtime migration to Java 25 LTS (nuclio/nuclio#4367). This branch carries four commits — the pre-existing in-flight
bump-javawork, the original Java 17 bytecode migration, a follow-up bumping that target to Java 25 once nuclio dropped armhf support, and a rewrite of Maven Central publishing. The SDK's public API (EventHandler,Context,Event, etc.) has zero deprecated/removed API usage and no runtime dependencies, so all four are build-tooling-only changes, not source changes:Commit 1 —
Update for newest version(pre-existing,bump-java):version1.1.0 → 1.2.0.classifier→archiveClassifier,testCompile/testRuntime→testImplementation/testRuntimeOnly,baseName→archivesBaseName.Commit 2 —
Migrate build tooling to Java 17 bytecode target and Gradle 9:junit-platform-gradle-pluginfor Gradle's nativetest { useJUnitPlatform() }, movesarchivesBaseNameinto the Gradle-9-compatiblebase {}block, replaces dead Travis CI with GitHub Actions.Commit 3 —
Bump SDK bytecode target to Java 25, drop the JDK 17 floor:java { toolchain { languageVersion = JavaLanguageVersion.of(25) } }) rather than a plainsourceCompatibility/targetCompatibilitypin — this auto-provisions a JDK 25 compiler via the Foojay resolver (newsettings.gradle), so contributors don't need JDK 25 pre-installed locally.--release 25requires the build's own JVM to already be JDK 25+.1.2.0— never actually published to Maven Central, so there's nothing to skip past.Commit 4 —
Publish via Maven Central Portal and sign all publication artifacts:oss.sonatype.org) shut down on 2025-06-30, so publishing could not succeed as written.com.vanniktech.maven.publish0.37.0: uploads through the Central Portal, generates sources/javadoc jars, and signs every artifact (jar, sources, javadoc, POM) via the publication — previously onlypom.ascwas uploaded.publishToMavenLocalworks without a key (it previously failed withCould not get unknown property 'signArchives').archivesconfiguration,pom.withXmlsigning andmodel {}rules — no Gradle deprecation warnings remain under--warning-mode all.Test plan
./gradlew buildunder the actual Gradle 9.7.1 wrapper, with the toolchain auto-downloading a JDK 25 — succeeds.javapthat the compiled class files are major version 69 (Java 25 bytecode), confirming the target took effect../gradlew build publishToMavenLocal --warning-mode allsucceeds without signing configured; published POM contains all Central-required fields..ascnext to jar, sources, javadoc, POM).1.1.0(not blocking: old bytecode still loads fine on the new JVMs). Requires:io.nuclionamespace verified on central.sonatype.com and a Portal user token inmavenCentralUsername/mavenCentralPassword(replacessonatypeUsername/sonatypePassword).signing.keyId/signing.password/signing.secretKeyRingFile, orsigningInMemoryKey/signingInMemoryKeyPassword../gradlew publishAndReleaseToMavenCentral.🤖 Generated with Claude Code