Early Validation of GoCD on Upcoming JDK Releases

Hi everyone,

I would like to share an idea we are currently considering: performing some external validation and tracking work around GoCD’s compatibility with future JDK versions.

This idea is not intended to ask the official project to raise its minimum Java baseline right now, nor to maintain multiple codebases, create separate official releases for different Java versions, or replace the existing test suite. Likewise, our goal is not to maintain a performance-focused fork.

From the current project setup, GoCD has already adopted Java 25 LTS in its build, testing, and release processes, while still keeping Java 17 as the minimum supported version for environments that bring their own JRE. This shows the project actively follows new Java LTS versions while also valuing compatibility for existing users’ runtime environments.

However, JDK versions will continue to evolve in the coming years. Even though GoCD currently supports and uses Java 25 LTS, future JDK upgrades may introduce dependency updates, runtime behavior changes, build toolchain adjustments, or cross-platform packaging differences. Therefore, we believe that performing early compatibility validation for future JDK versions could be helpful for ongoing maintenance.

Our goal is to externally validate GoCD’s compatibility with JDK versions beyond Java 25, including future JDK releases such as JDK 26, JDK 27, or later LTS baselines.

This validation could help identify potential issues earlier, such as:

• Compilation or build failures
• Unit or integration test failures
• Runtime behavior differences
• Gradle / JRuby / server-agent communication compatibility issues
• Third-party dependency compatibility problems on newer JDKs
• Runtime or packaging differences across Windows, macOS, and Linux
• CI and development environment configuration issues
• Issues users may encounter when running GoCD on newer Java environments

Our current plan is to maintain a small number of external experimental compatibility branches or test environments for newer JDK versions. The official project can continue normal development on the current main branch, current minimum Java baseline, current release JDK version, and existing release cadence. We would take responsibility for syncing upstream code, running relevant tests, recording issues, and maintaining these experimental validation efforts.

These branches or test environments are not intended to become official separate codebases unless the project and community later see clear value in them. At this stage, their primary purpose is compatibility validation, collecting feedback, and preparing reference information that could be useful for future migration or adaptation to newer JDKs.

If there is real demand, we may maintain two or three external compatibility validation branches or test configurations over the long term and report useful findings or small, focused PRs upstream. For issues that can be addressed independently, we would document them as reproducible issues or submit small, focused PRs instead of asking the project to review or maintain a large fork.

The goal of this effort is to identify potential compatibility risks GoCD may face on future JDK versions as early as possible, and provide useful information for future JDK upgrades or adaptation work without adding extra maintenance burden to the official project.

Thank you for your time, and thank you for maintaining GoCD.