Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Allow to provide source file java language version

未關閉
#975 0 則留言 1 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
38/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
停滯
技術堆疊
java
領域
tooling

研究方向

先追蹤 google-java-format 如何接受 parser 和命令列選項,接著檢視 JLS Section 3.8 中對版本相關保留識別碼的討論。判斷 source 或 release 哪個是適合作為面向使用者的選項,並驗證使用 var、yield 或 record 等識別碼格式化較舊的 Java 原始碼可以成功,同時目前原始碼的格式化維持不變。

由索引模型根據 Issue 內容生成。

描述

When formatting files with google-java-format, the parser uses the same source version as its own runtime version (running google-java-format on JDK X implies that that Java source files are conformant with JDK X), but this is actually not necessary true and files may be aiming for a different (older) Java version. Nowadays it is a common pattern to use --release flag to compiler for a specific older version of the language using a newer JDK.

Unfortunately Java language is not fully backward compatible and some features have introduced breaking changes like reserved identifiers var, with, yieldorrecord` (see current list in JLS Section 3.8)

For files who were designed to compile with an older Java version and who are using now reserved identifiers, this cause their processing with google-java-format using a recent JDK version to fail.

A solution would be to allow to pass either the source or the release option to the java parser to adapt its own parsing to the java version used by the file.

主要語言
Java
星號
6.2k
分支
936
平均合併
6 分鐘
30 天內合併 PR
3

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

google/google-java-format 的其他 Issue

查看 google/google-java-format 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。