External Compatibility Validation for google-java-format on Future JDK Versions

Hi everyone,

I would like to share an idea we are currently considering: doing some external validation and tracking work around google-java-format’s compatibility with future JDK versions.

This is not a request for the official project to maintain multiple codebases, create separate official releases for different Java versions, or replace the existing test suite. Our goal is also not to maintain a performance-focused fork.

From the current project setup, google-java-format relies on `jdk.compiler` / javac-related APIs to parse and format Java source code. This makes it sensitive to the runtime JDK version, new Java language syntax, and changes in JDK internal APIs. The project has already raised its minimum runtime JDK requirement to JDK 21 and continues to track compatibility with newer JDK versions and Java language features.

Because of that, our goal is not to ask the project to maintain multiple Java baselines or change the current minimum runtime JDK requirement. Instead, we would like to do early compatibility validation around future JDK versions, so that potential issues in newer JDK environments can be identified earlier.

This kind of validation may include, but is not limited to:

* Compatibility issues when running the formatter on JDK 22, JDK 23, JDK 24, JDK 25, or later versions
* Formatting differences caused by new Java syntax or preview features
* Formatting issues related to Javadoc / Markdown documentation comments or other documentation syntax changes
* Issues caused by changes in `jdk.compiler` / javac internal APIs
* Java module system access restrictions or `--add-exports` related issues
* Compatibility differences in CLI, IDE plugin, Maven, or Gradle integration scenarios
* CI, build script, or test environment compatibility issues
* Issues users may encounter when using google-java-format on newer JDK environments

Our current idea is to maintain a small number of external experimental compatibility branches or test environments for future JDK versions. The official project can continue normal development on the current main branch, current minimum runtime JDK requirement, and existing release cadence. We would take responsibility for syncing with upstream, 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 in them. At this stage, their main purpose would be compatibility validation, collecting feedback, and preparing useful reference information for future adaptation to new JDKs or Java language features.

If there is real demand, we may maintain two or three external compatibility validation branches or test configurations for future JDK versions over the long term and report useful findings upstream when helpful. 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 google-java-format may face with future JDK versions, new Java language syntax, and javac-related API changes as early as possible, and to provide useful information for future adaptation work without adding extra maintenance burden to the official project.

Thank you for your time, and thank you for maintaining google-java-format.

Nenhum arquivo, teste ou ponto de entrada específico foi identificado. Primeiro, revise a CI existente, os scripts de build e o ambiente de testes; depois, esclareça quais versões futuras do JDK e cenários de validação estão no escopo; o trabalho estará concluído quando houver uma configuração experimental ou branch acordado com descobertas de compatibilidade reproduzíveis.

Escrita pelo modelo de indexação a partir do texto da issue.