External Validation for HertzBeat Compatibility Beyond Java 17

### Volunteer help

Hi everyone,

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

This idea is not intended to ask the official project to immediately raise the minimum Java baseline, 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, HertzBeat has already gone through upgrades from Java 11 to Java 17, and the current main branch already shows requirements for JDK 25 or higher. This indicates that the project actively follows new Java LTS releases while also valuing compatibility for existing users’ runtime environments.

However, JDK versions will continue to evolve over the next few years. Even though Java 25 is currently in use, future upgrades may introduce dependency changes, runtime behavior differences, build toolchain adjustments, and cross-platform packaging issues. Therefore, we believe that performing early compatibility validation for future JDK versions could be helpful for ongoing maintenance.

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

This validation may help surface potential issues earlier, including:

* Compilation or build failures
* Unit or integration test failures
* Runtime behavior differences
* Compatibility issues with backend dependencies (e.g., Spring Boot, Netty, Protobuf, Guava) on newer JDKs
* CI, build script, or test environment compatibility issues
* Runtime or packaging differences across Windows, macOS, and Linux
* Issues users may encounter on newer Java runtime environments

Our current approach 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 find clear value. At this stage, their main purpose is compatibility validation, collecting feedback, and preparing useful reference information for future migration or adaptation to newer JDKs.

If there is real demand, we may maintain two or three external compatibility 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 rather than asking the project to review or maintain a large fork.

The goal of this effort is to identify potential compatibility risks HertzBeat 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 HertzBeat.

No specific file, test, or entry point is named; start by reviewing the current Java baseline, build scripts, CI configuration, and existing test setup. Validate newer JDK environments across the mentioned platforms and dependencies, then record reproducible compatibility findings or submit only small, focused fixes.

Written by the indexing model from the issue text.