FirstSpirit will run on Java 25 starting with release 2026.11 in SaaS environments

Summary

• With the 2026.11 patch day, FirstSpirit in our SaaS environments switches its runtime from Java 21 to Java 25 (Eclipse Temurin 25, the next long-term-support release).
• The rollout follows the usual patch-day cycle: DEV and QA environments first, PROD one week later.
• Your Compatibility plans now include a Java 25 job. A passed Java 25 job is the readiness signal for your module. A failing one tells you what to fix, and in most cases the fix is an updated Gradle wrapper, not a code change.
• Please check your Compatibility plans and review failing jobs.

What changes, and when

The week between the two dates is your chance to verify your modules on a real Java 25 server before production follows. Please use it: test your project's key workflows on DEV/QA (editing, preview, generation, deployment, and every function provided by your own modules).

What does not change: the Java language level of your modules. A module compiled for Java 21 (or 17) bytecode is compatible with a Java 25 server. You do not need to raise java.languageLevel / maven.compiler.release.

Do I need to do anything?

Compatibility plans now test Java 25

As introduced with the Java 21 article, every module repository on our CI has a "Compatibility and Compliance" plan (or a "Compatibility" plan for older layouts). It rebuilds your module against the Java versions that matter for the platform, independently of your regular build.

The jobs are now:

The plans run unchanged otherwise: weekly on the master branch (weekends), and on every commit on any branch. So pushing a fix to a branch gives you a result within minutes.

Separate two things: the build JDK and the runtime JDK

A Compatibility job does two things at once: it runs your build tool (Gradle or Maven) on the target JDK, and it compiles your module against it. Most unsuccessful Java 25 jobs fail in the first step: the build tool is too old to start on Java 25, so the job fails before a single line of your module's code is compiled. The error message then points at Gradle, not at your module.

That is good news: the fix is in the build setup, and usually no module code changes.

Typical failures and how to fix them

Ordered by how often we see them.

1. Gradle is too old for Java 25 (by far the most common)

Symptom (one of these, early in the log, often while compiling settings.gradle(.kts)):

java.lang.IllegalArgumentException: 25.0.x

Unsupported class file major version 69

Cause: Each Java version needs a minimum Gradle version to run Gradle on it. For Java 25 that is Gradle 9.1.0; for Java 21 it is Gradle 8.5. The Java 21 job may still be successful with your current Gradle, which confirms it is a toolchain limit, not a code problem.

Fix: Upgrade the Gradle wrapper to the latest release (9.8.1 as of October): 

./gradlew wrapper --gradle-version <9.x>

(execute twice to ensure wrapper binary has been replaced)

The jump to Gradle 9 is a major upgrade. Expect these follow-up changes:

• FirstSpirit Module Gradle plugin: older plugin releases do not run on Gradle 9. Raise de.espirit.firstspirit-module to a release that supports Gradle 9 [9.0.2 as of October].

  id("de.espirit.firstspirit-module") version "9.0.2"

• JUnit: Gradle 9 no longer adds the JUnit Platform launcher automatically. Add it explicitly:

  testRuntimeOnly("org.junit.platform:junit-platform-launcher")
  

• Other build plugins (release, publishing, code quality): check they support Gradle 9 and upgrade them if not.
• Deprecated build-script APIs that Gradle 8 only warned about are removed in Gradle 9. Run the build and fix what the error output names. The Gradle 9 upgrade guide lists the changes.

Then push the branch and check that both the Java 21 and the Java 25 job are passing.

2. checkCompliance task not found

Symptom: the Compliance job fails with Task 'checkCompliance' not found in root project ….

Fix: The task is part of the FirstSpirit Module Gradle plugin 6.5.0 and newer. Upgrade the plugin to the latest version (9.0.2 as of October) ; if you do step 1, the plugin upgrade there covers this too.

id("de.espirit.firstspirit-module") version "9.0.2"

Please see section How to support compatibility plans? as described in the Java 21 article for more details.

3. rootProjectName empty

Symptom: the build fails while evaluating the project because the project name is empty.

This is an indicator that your repository is in an early state.

Fix: Set rootProjectName=your-project-name in gradle.properties. 
Please see section How to support compatibility plans? as described in the Java 21 article for more details.

4. Compliance rule violations

Symptom: the Compliance job runs and reports ArchUnit rule violations, e.g. doNotDependOnRuntimeClasses.

Fix: Replace the reported usages of non-public FirstSpirit classes with the public API. This is unrelated to Java 25, but it only becomes visible once the build itself runs.

5. Build setup problems

Less frequent, but they block all jobs of a plan:

One fix can uncover the next. A job stops at the first error. After you upgrade Gradle, a compile error or compliance violation that was hidden behind it may appear. Repeat until both jobs are passing.

Runtime: what a successful plan does not cover

A successful Java 25 job proves that your module builds on Java 25. It does not prove that it behaves the same at runtime. Java bytecode compatibility is very good, and most modules need no change, but please test on DEV/QA in CW 42 if your module or one of its libraries does any of the following:

• Uses the Security Manager (System.setSecurityManager, AccessController, policy files). It is permanently disabled since Java 24.
• Generates or reads bytecode at runtime, through older versions of libraries such as ASM, Byte Buddy, cglib, Javassist or Groovy. Versions that do not know Java 25 class files (version 69) fail when they touch JDK classes. Upgrade them.
• Uses sun.misc.Unsafe memory-access methods or JNI. Java 24 and later print warnings for these, in preparation for future restrictions.
• Formats dates, numbers or currencies with locale-specific patterns and relies on the legacy COMPAT locale data, which was removed in Java 23. Output may differ slightly.
• Bundles old third-party libraries in general. Check their documentation for Java 25 support.

If something behaves differently on DEV/QA, contact support before the PROD date.

Questions

If you have questions or issues, please submit them at https://support.rezolve.com or by email to support@rezolve.com.

Include the name of your Bamboo plan and a link to the failed job result.