Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#1,395 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
静か
技術スタック
java
領域
ci-cd, tooling

調査の方向性

特定のファイル、テスト、エントリーポイントは特定されていません。まず既存のCI、ビルドスクリプト、テスト環境を確認し、その後、どの将来のJDKバージョンと検証シナリオを対象とするかを明確にします。完了条件は、合意された実験的な構成または再現可能な互換性の調査結果を含むブランチです。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Java
スター
6.2k
フォーク
936
平均マージ
6分
マージ済み PR(30日)
3

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

google/google-java-format のほかの issue

google/google-java-format の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。