第一次运行 JDK17 的新项目pom 文件检查过、Project Structure 也设成了 17环境变量看起来都对结果 Maven 一执行就报无效的标记: --release。这问题我隔三差五在技术群里看到新人问一遍老手答一遍本质全部指向同一件事真正跑编译的 javac 不是 JDK17甚至不是 JDK9它根本不认识--release这个参数。这篇就把这个错误的完整排查链路写透给所有从 JDK8/11 升到 JDK17、或者新装 JDK 后第一次跑 Maven 项目的人做个参考。1. 报错现场配置全对javac 却认不出 --release1.1 先复现一遍这个坑典型场景是这样的项目刚从 GitHub 拉下来或者本地新建代码用的是 Java 17 语法pom.xml 里也写了properties maven.compiler.release17/maven.compiler.release /propertiesIDEA 里File - Project Structure - Project SDK已经选了 17Modules 的 Language level 也是 17。看起来所有配置都到位了结果点 Maven 面板的clean compile控制台直接报[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1.0:compile (default-compile) on project demo: Compilation failure [ERROR] 无效的标记: --release有些环境还会在[ERROR]之前带一句完整的 javac 诊断信息。如果你用的 IDE 把详细输出折叠了很容易只看到一个笼统的无效的标记这时候第一反应通常是去翻 pom觉得 Maven 插件参数拼错了。实际上这个提示是从 javac 命令行解析器里冒出来的不是 Maven 自己发明的错误。1.2 为什么“配置没问题”恰恰是最误导人的信息我见过太多人卡在这个报错上超过半小时就是因为陷入了“我哪里都检查了”的自我怀疑。但冷静想一下--release是 javac 的参数报错说“无效的标记”那就说明 javac 不认识它。JDK8 的 javac 确实不认--releaseJDK9 开始才加入这个开关。所以这个报错本身就是在告诉你你机器上实际执行编译的 javac根本不是 JDK17甚至不是 JDK9 或 JDK11。你检查的“项目配置”和“实际编译链路”是两套东西。IDEA 的 Project SDK、Maven 面板里的 Runner JRE、系统环境变量 JAVA_HOME、PATH 里的 javac这四者可以分别指向四个不同版本的 JDK。初学者往往只检查其中一两个自然会得出“配置没问题”的结论。打个比方你订好了高铁票目的地写得很清楚结果跑到老火车站去坐绿皮车绿皮车系统里根本没有“高铁班次”这个选项。报错信息不是车次问题而是你检票进错了站。2. --release 为什么会“无效”参数来源与实际 JDK 版本错位2.1 --release 是谁用来干什么--release是 JDK9 引入的 javac 参数作用是用一个参数同时替代-source和-target并且额外带上“API 签名检查”。以前用 Java 8 编译老项目常见配置是maven.compiler.source8/maven.compiler.source maven.compiler.target8/maven.compiler.target-source 8控制语法版本-target 8控制生成的字节码版本。但有个经典坑你明明设了-target 8代码里却调用了 JDK9 才出现的 API比如List.of()。javac 在编译期可能放行因为这个 API 是当前 JDK 里存在的结果这段字节码丢到 Java8 运行环境里直接NoSuchMethodError。--release 8解决的就是这个问题它不仅按 Java8 语法编译还把“JDK 内置 API 的可见范围”也限制成 Java8 的版本列表。代码里用了更新版本的 JDK API编译期就会报“程序包 xxx 不存在”之类的错误。简单说-source/-target只管“怎么写、编成什么样”--release连“能用哪些库”都一起管了。这也是官方推荐用--release而不是-source/-target的原因。2.2 报错信息说明了什么无效的标记: --release翻译成人话就是javac 的命令行解析器看到一个不认识的 flag。JDK8 的javac -help里没有--release它只接受-source、-target、-bootclasspath这类老参数。当 Maven 把--release 17传给 JDK8 的 javac 时解析器直接拒绝无效的标记。这里有个更容易懵的细节你运行java -version可能显示的是 JDK17但编译报错时用的 javac 却来自 JDK8。java和javac是两个可执行文件它们所在的 bin 目录不一定相同。Windows 上尤其常见Oracle 老 JDK 安装时会在 PATH 前面插入一个公共 javapath指向某个固定版本或者你调用了C:\Windows\System32\java.exe而javac又在另一个路径。所以看到java -version正常不代表javac -version也正常。2.3 Maven 是怎么把 pom 变成 javac 命令的Maven 编译阶段由 maven-compiler-plugin 负责。插件读取项目属性最终拼出类似下面这样的 javac 调用javac --release 17 -d target/classes ...关键变量映射如下pom 配置传给 javac 的参数maven.compiler.release--releasemaven.compiler.source-sourcemaven.compiler.target-targetmaven.compiler.fork executable指定外部 javacMaven 进程运行在哪个 JDK 上负责编译的 javac 基本就是哪个 JDK 的 javac——除非你做了 fork 并指定了别的可执行文件。所以排查的第一步不是看 pom而是先确认 Maven 自己跑在什么 Java 上。3. 逐步定位让真正执行编译的 JDK 现出原形3.1 命令行三板斧java、javac、mvn -v不管你在 Windows、macOS 还是 Linux先打开终端跑三个命令以实际输出为准不要凭印象java -version javac -version mvn -v前两个看 JDK 可执行文件第三个看 Maven 运行时环境。如果javac -version输出类似javac 1.8.0_311那么问题已经水落石出编译用的就是 JDK8。mvn -v通常会在前面几行打印Apache Maven 3.8.8 Java version: 1.8.0_311Java version 一栏同样会暴露问题。命令行 Maven 跑在 JDK8 上它调用 javac 时自然也是 JDK8。这时候 pom 里配置再华丽--release都传不进去。Windows 上还要再补一步查看命令实际定位到哪个文件where java where javac如果where javac第一个结果是C:\Program Files\Common Files\Oracle\Java\javapath\javac.exe这通常意味着 PATH 里残留了 Oracle 的公共 Java 路径优先级还很高。macOS/Linux 用which java和which javac同理。3.2 JAVA_HOME 到底指向哪命令行 Maven 启动时mvn脚本默认靠 JAVA_HOME 找 java。所以环境变量这一步不能跳Windowsecho %JAVA_HOME%macOS/Linuxecho $JAVA_HOME常见问题有几种JAVA_HOME 为空Maven 可能走 PATH 里的 java。JAVA_HOME 指向老 JDK比如C:\Program Files\Java\jdk1.8.0_311。JAVA_HOME 拼写或末尾反斜杠有问题路径实际不存在。指向了 JRE 而不是 JDK。只装了 JRE 的话 bin 目录里没有 javac编译时通常报“找不到 javac”而不是“无效的标记”。同时要确认 PATH 里是否包含%JAVA_HOME%\bin并且它排在系统自带 java 路径之前。Windows 有个经典坑C:\Windows\System32\java.exe是微软放的一个公共执行文件如果 PATH 里它排在 JDK 的 bin 前面终端里java -version显示的就不是你安装的版本。3.3 mvn -v 显示 Java 17 就放心了并没有很多人修完环境变量命令行mvn -v已经显示 Java 17回 IDEA 再点 Maven 面板还是报同样的错。原因很简单IDEA 里的 Maven 不归系统 PATH 管。IDEA 在执行 Maven 构建时用的是Settings - Build, Execution, Deployment - Build Tools - Maven里的配置重点关注两个地方Importing页签下的JDK for importer负责 Maven 导入项目模型、解析依赖时使用的 JDK。Runner页签下的JRE执行 Maven 构建命令时使用的 Java 运行时。很多情况下 Project SDK 是 17但 Runner JRE 还是默认的1.8或其他旧版本。你检查了项目结构没检查 Maven Runner于是 IDEA 里的构建一直用旧 JDK。命令行已经修好的用户在 IDEA 里继续报错多半就是这里没改。可以把三处来源做个对照位置控制的内容常见误区Project Structure - SDKIDE 语法解析、原生 Build 的 javac以为它也管 MavenMaven - Runner - JREMaven 执行时用的 JDK经常被遗忘系统 JAVA_HOME命令行 mvn 的 JDK改了不重开终端不生效如果你最终目标是“命令行和 IDEA 都能构建”这三处必须一致如果只追求 IDEA 能构建至少 Runner JRE 要指向 17。4. 动手修复从 JAVA_HOME 到 Runner JRE再到 pom 插件版本4.1 让 JAVA_HOME 和 PATH 同时指向同一个 JDK17修复第一步把环境变量统一指到 JDK17 安装目录。Windows 图形界面里设置系统环境变量的步骤不啰嗦只说关键点JAVA_HOME 设为C:\Program Files\Java\jdk-17这类实际路径不要带\bin。PATH 里确保有%JAVA_HOME%\bin并且把老 JDK、Oracle javapath、C:\Windows\System32中带 java.exe 的条目往后排。改完必须新开终端或让 IDE 完全重启环境变量才会刷新。临时验证可以在 cmd 里执行set JAVA_HOMEC:\Program Files\Java\jdk-17 set PATH%JAVA_HOME%\bin;%PATH% java -version javac -version输出都变成 17 之后再跑mvn -v确认 Java version 一栏是 17。这样命令行这一路就通了。macOS 上如果你用 Homebrew 安装的 openjdk17建议先brew info openjdk17看提示的路径把 JAVA_HOME 指向那个目录或者用/usr/libexec/java_home -v 17动态获取。用 sdkman 的用户则是sdk use java 17.x.x-tem后直接验证。4.2 IDEA 里把 Maven 的执行 JDK 改到 17改完环境变量回到 IDEASettings - Build, Execution, Deployment - Build Tools - Maven - Importing把JDK for importer选成 17。Settings - Build, Execution, Deployment - Build Tools - Maven - Runner把JRE选成项目 SDK 或具体 JDK17。注意如果你用的是 IDEA 自带的 Maven runner改完设置后最好把 Maven 面板里的Reload All Maven Projects点一下让 IDEA 用新的 JDK 重新解析项目。有些老版本 IDEA 改完 Runner 不重启也生效但保险起见重启一次 IDE 最省心。如果项目用了mvnwMaven Wrapper还要确认 wrapper 脚本执行时读取的 JAVA_HOME 也是 17。IDEA Terminal 里跑./mvnw -v看一眼输出别只看全局mvn -v就收工。4.3 pom.xml 里锁一个现代 compiler 插件版本环境变量和 IDEA 都修好之后正常情况下问题已经消失。但还有一类场景是JDK 是 17环境也对报错却变成别的形态或者仍然顽固。这时候要检查 maven-compiler-plugin 本身。maven.compiler.release这个属性不是所有 compiler 插件版本都认。老项目如果父 POM 里显式把 compiler 插件锁在 2.x 或 3.1 这类远古版本即使 Maven 跑在 JDK17 上插件也可能不会正确读取release属性或生成的 javac 命令不符合预期。建议直接在buildplugins里锁一个较新的插件版本plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.11.0/version /plugin同时用属性统一编译目标properties maven.compiler.release17/maven.compiler.release /properties我推荐 3.11.0 的原因是它对release属性支持得很完整配 JDK17、JDK21 都没问题。如果项目还在用 Java8 目标也可以把 release 改成 8比如--release 8语法和 API 都按 Java8 来。锁版本之前先看实际生效的配置mvn help:effective-pom effective-pom.txt打开这个文件搜maven-compiler-plugin能看到最终使用的插件版本这比凭记忆猜准确得多。4.4 最后验证用一条命令确认端到端跑通全部改完后建议按这个顺序验证先写一个最小测试类public class Hello { public static void main(String[] args) { System.out.println(JDK17 OK); } }命令行手动编译一次javac --release 17 Hello.java java Hello这一步直接验证当前终端的 javac 是否支持--release 17。如果这条命令能过说明环境没问题剩下的就是 Maven 链路。再执行mvn clean compile如果项目还是报错加-X打开调试日志mvn clean compile -X mvn-debug.log在日志里搜javac或--release能看到 Maven 实际传给 javac 的完整参数以及它启用了哪个 java 可执行文件。这一步往往能让隐藏的 fork 配置现形。5. 同类坑的变种release 混用、Gradle 与 CI 环境5.1 release 和 source/target 混用会引发新的冲突修好环境之后另一个高频问题浮出水面pom 里既要maven.compiler.release17又保留老项目的maven.compiler.source和maven.compiler.target。JDK17 的 javac 明确规定--release不能和--source/--target同时使用。一旦同时出现报错是error: option --source cannot be used together with --release所以升级项目时正确做法是删掉 source/target 两个属性只保留 release。它一个参数就同时约束了语法、字节码和 API 可见性。这也是从 JDK8 迁移到 17 时顺手做掉的整理工作。这里多说一句团队里如果还有人用 JDK8 跑这个 pommaven.compiler.release17会让 JDK8 的 javac 直接报“无效的标记”——因为 JDK8 不认这个参数。所以项目统一了 JDK17 之后这种报错会从“跑不了的 Maven 环境”变成“拒绝人人都有 JDK17”的团队约束本质是好事。5.2 Gradle 和 CI 里一模一样的版本错位Gradle 项目也会有相似的错误报错的字符串可能不太一样但本质还是版本错位。Gradle 里通常会写compileJava { options.release 17 }或者用 toolchainjava { toolchain { languageVersion JavaLanguageVersion.of(17) } }toolchain 是自动选 JDK不需要用户手动设置 JAVA_HOME。但如果 Gradle 版本太老比如 6.x它对 Java17 的支持就是缺失的编译 JDK17 代码会失败或者行为异常。建议 Gradle wrapper 升到 7.3 以上用 8.x 更省心。同类排查思路不变先看gradle -v里的 JVM 版本再看项目 toolchain 指定版本是否匹配。CI 上更常见的是“本地好好的流水线一跑就报”。原因通常是流水线镜像里 Maven 默认 Java 是 8或者 setup-java action 设置了 17但后面某个步骤又把 PATH 里的 java 换掉了。CI 的 Dockerfile 里最好显式固定 JDK 路径并且在执行构建前打印一次三连版本java -version javac -version mvn -v这一步放到流水线日志里比事后翻历史构建记录省事太多。5.3 从根源上减少这类环境漂移的三个习惯第一每次切换 JDK 后第一件事不是打开 IDE而是跑一遍java -version javac -version mvn -v。十秒钟就能发现版本错位省掉后面半小时的排查。第二pom 或 build.gradle 里只写 release不写 source/targetMaven 项目明确锁住 maven-compiler-plugin 版本。让编译参数来源单一化别给“属性相互覆盖”留机会。第三团队项目里用.sdkmanrc、Maven Wrapper 或者统一安装脚本管理 JDK不要靠每个人手动改环境变量。新同事入职配环境时少走弯路线上构建也更稳定。我自己第一次遇到这个错时当时还没意识到 javac 和 java 可能来自不同 JDK爬了半天 pom。后来养成了“先把执行链路每一环的版本打印出来”的习惯绝大多数编译期怪问题都能在两条命令之内定位。无效的标记: --release这个报错看着唬人其实只是在替你大喊你编译用的 JDK 不是你想象的那个。
Maven编译报错无效的标记 --release 的JDK版本排查指南
第一次运行 JDK17 的新项目pom 文件检查过、Project Structure 也设成了 17环境变量看起来都对结果 Maven 一执行就报无效的标记: --release。这问题我隔三差五在技术群里看到新人问一遍老手答一遍本质全部指向同一件事真正跑编译的 javac 不是 JDK17甚至不是 JDK9它根本不认识--release这个参数。这篇就把这个错误的完整排查链路写透给所有从 JDK8/11 升到 JDK17、或者新装 JDK 后第一次跑 Maven 项目的人做个参考。1. 报错现场配置全对javac 却认不出 --release1.1 先复现一遍这个坑典型场景是这样的项目刚从 GitHub 拉下来或者本地新建代码用的是 Java 17 语法pom.xml 里也写了properties maven.compiler.release17/maven.compiler.release /propertiesIDEA 里File - Project Structure - Project SDK已经选了 17Modules 的 Language level 也是 17。看起来所有配置都到位了结果点 Maven 面板的clean compile控制台直接报[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1.0:compile (default-compile) on project demo: Compilation failure [ERROR] 无效的标记: --release有些环境还会在[ERROR]之前带一句完整的 javac 诊断信息。如果你用的 IDE 把详细输出折叠了很容易只看到一个笼统的无效的标记这时候第一反应通常是去翻 pom觉得 Maven 插件参数拼错了。实际上这个提示是从 javac 命令行解析器里冒出来的不是 Maven 自己发明的错误。1.2 为什么“配置没问题”恰恰是最误导人的信息我见过太多人卡在这个报错上超过半小时就是因为陷入了“我哪里都检查了”的自我怀疑。但冷静想一下--release是 javac 的参数报错说“无效的标记”那就说明 javac 不认识它。JDK8 的 javac 确实不认--releaseJDK9 开始才加入这个开关。所以这个报错本身就是在告诉你你机器上实际执行编译的 javac根本不是 JDK17甚至不是 JDK9 或 JDK11。你检查的“项目配置”和“实际编译链路”是两套东西。IDEA 的 Project SDK、Maven 面板里的 Runner JRE、系统环境变量 JAVA_HOME、PATH 里的 javac这四者可以分别指向四个不同版本的 JDK。初学者往往只检查其中一两个自然会得出“配置没问题”的结论。打个比方你订好了高铁票目的地写得很清楚结果跑到老火车站去坐绿皮车绿皮车系统里根本没有“高铁班次”这个选项。报错信息不是车次问题而是你检票进错了站。2. --release 为什么会“无效”参数来源与实际 JDK 版本错位2.1 --release 是谁用来干什么--release是 JDK9 引入的 javac 参数作用是用一个参数同时替代-source和-target并且额外带上“API 签名检查”。以前用 Java 8 编译老项目常见配置是maven.compiler.source8/maven.compiler.source maven.compiler.target8/maven.compiler.target-source 8控制语法版本-target 8控制生成的字节码版本。但有个经典坑你明明设了-target 8代码里却调用了 JDK9 才出现的 API比如List.of()。javac 在编译期可能放行因为这个 API 是当前 JDK 里存在的结果这段字节码丢到 Java8 运行环境里直接NoSuchMethodError。--release 8解决的就是这个问题它不仅按 Java8 语法编译还把“JDK 内置 API 的可见范围”也限制成 Java8 的版本列表。代码里用了更新版本的 JDK API编译期就会报“程序包 xxx 不存在”之类的错误。简单说-source/-target只管“怎么写、编成什么样”--release连“能用哪些库”都一起管了。这也是官方推荐用--release而不是-source/-target的原因。2.2 报错信息说明了什么无效的标记: --release翻译成人话就是javac 的命令行解析器看到一个不认识的 flag。JDK8 的javac -help里没有--release它只接受-source、-target、-bootclasspath这类老参数。当 Maven 把--release 17传给 JDK8 的 javac 时解析器直接拒绝无效的标记。这里有个更容易懵的细节你运行java -version可能显示的是 JDK17但编译报错时用的 javac 却来自 JDK8。java和javac是两个可执行文件它们所在的 bin 目录不一定相同。Windows 上尤其常见Oracle 老 JDK 安装时会在 PATH 前面插入一个公共 javapath指向某个固定版本或者你调用了C:\Windows\System32\java.exe而javac又在另一个路径。所以看到java -version正常不代表javac -version也正常。2.3 Maven 是怎么把 pom 变成 javac 命令的Maven 编译阶段由 maven-compiler-plugin 负责。插件读取项目属性最终拼出类似下面这样的 javac 调用javac --release 17 -d target/classes ...关键变量映射如下pom 配置传给 javac 的参数maven.compiler.release--releasemaven.compiler.source-sourcemaven.compiler.target-targetmaven.compiler.fork executable指定外部 javacMaven 进程运行在哪个 JDK 上负责编译的 javac 基本就是哪个 JDK 的 javac——除非你做了 fork 并指定了别的可执行文件。所以排查的第一步不是看 pom而是先确认 Maven 自己跑在什么 Java 上。3. 逐步定位让真正执行编译的 JDK 现出原形3.1 命令行三板斧java、javac、mvn -v不管你在 Windows、macOS 还是 Linux先打开终端跑三个命令以实际输出为准不要凭印象java -version javac -version mvn -v前两个看 JDK 可执行文件第三个看 Maven 运行时环境。如果javac -version输出类似javac 1.8.0_311那么问题已经水落石出编译用的就是 JDK8。mvn -v通常会在前面几行打印Apache Maven 3.8.8 Java version: 1.8.0_311Java version 一栏同样会暴露问题。命令行 Maven 跑在 JDK8 上它调用 javac 时自然也是 JDK8。这时候 pom 里配置再华丽--release都传不进去。Windows 上还要再补一步查看命令实际定位到哪个文件where java where javac如果where javac第一个结果是C:\Program Files\Common Files\Oracle\Java\javapath\javac.exe这通常意味着 PATH 里残留了 Oracle 的公共 Java 路径优先级还很高。macOS/Linux 用which java和which javac同理。3.2 JAVA_HOME 到底指向哪命令行 Maven 启动时mvn脚本默认靠 JAVA_HOME 找 java。所以环境变量这一步不能跳Windowsecho %JAVA_HOME%macOS/Linuxecho $JAVA_HOME常见问题有几种JAVA_HOME 为空Maven 可能走 PATH 里的 java。JAVA_HOME 指向老 JDK比如C:\Program Files\Java\jdk1.8.0_311。JAVA_HOME 拼写或末尾反斜杠有问题路径实际不存在。指向了 JRE 而不是 JDK。只装了 JRE 的话 bin 目录里没有 javac编译时通常报“找不到 javac”而不是“无效的标记”。同时要确认 PATH 里是否包含%JAVA_HOME%\bin并且它排在系统自带 java 路径之前。Windows 有个经典坑C:\Windows\System32\java.exe是微软放的一个公共执行文件如果 PATH 里它排在 JDK 的 bin 前面终端里java -version显示的就不是你安装的版本。3.3 mvn -v 显示 Java 17 就放心了并没有很多人修完环境变量命令行mvn -v已经显示 Java 17回 IDEA 再点 Maven 面板还是报同样的错。原因很简单IDEA 里的 Maven 不归系统 PATH 管。IDEA 在执行 Maven 构建时用的是Settings - Build, Execution, Deployment - Build Tools - Maven里的配置重点关注两个地方Importing页签下的JDK for importer负责 Maven 导入项目模型、解析依赖时使用的 JDK。Runner页签下的JRE执行 Maven 构建命令时使用的 Java 运行时。很多情况下 Project SDK 是 17但 Runner JRE 还是默认的1.8或其他旧版本。你检查了项目结构没检查 Maven Runner于是 IDEA 里的构建一直用旧 JDK。命令行已经修好的用户在 IDEA 里继续报错多半就是这里没改。可以把三处来源做个对照位置控制的内容常见误区Project Structure - SDKIDE 语法解析、原生 Build 的 javac以为它也管 MavenMaven - Runner - JREMaven 执行时用的 JDK经常被遗忘系统 JAVA_HOME命令行 mvn 的 JDK改了不重开终端不生效如果你最终目标是“命令行和 IDEA 都能构建”这三处必须一致如果只追求 IDEA 能构建至少 Runner JRE 要指向 17。4. 动手修复从 JAVA_HOME 到 Runner JRE再到 pom 插件版本4.1 让 JAVA_HOME 和 PATH 同时指向同一个 JDK17修复第一步把环境变量统一指到 JDK17 安装目录。Windows 图形界面里设置系统环境变量的步骤不啰嗦只说关键点JAVA_HOME 设为C:\Program Files\Java\jdk-17这类实际路径不要带\bin。PATH 里确保有%JAVA_HOME%\bin并且把老 JDK、Oracle javapath、C:\Windows\System32中带 java.exe 的条目往后排。改完必须新开终端或让 IDE 完全重启环境变量才会刷新。临时验证可以在 cmd 里执行set JAVA_HOMEC:\Program Files\Java\jdk-17 set PATH%JAVA_HOME%\bin;%PATH% java -version javac -version输出都变成 17 之后再跑mvn -v确认 Java version 一栏是 17。这样命令行这一路就通了。macOS 上如果你用 Homebrew 安装的 openjdk17建议先brew info openjdk17看提示的路径把 JAVA_HOME 指向那个目录或者用/usr/libexec/java_home -v 17动态获取。用 sdkman 的用户则是sdk use java 17.x.x-tem后直接验证。4.2 IDEA 里把 Maven 的执行 JDK 改到 17改完环境变量回到 IDEASettings - Build, Execution, Deployment - Build Tools - Maven - Importing把JDK for importer选成 17。Settings - Build, Execution, Deployment - Build Tools - Maven - Runner把JRE选成项目 SDK 或具体 JDK17。注意如果你用的是 IDEA 自带的 Maven runner改完设置后最好把 Maven 面板里的Reload All Maven Projects点一下让 IDEA 用新的 JDK 重新解析项目。有些老版本 IDEA 改完 Runner 不重启也生效但保险起见重启一次 IDE 最省心。如果项目用了mvnwMaven Wrapper还要确认 wrapper 脚本执行时读取的 JAVA_HOME 也是 17。IDEA Terminal 里跑./mvnw -v看一眼输出别只看全局mvn -v就收工。4.3 pom.xml 里锁一个现代 compiler 插件版本环境变量和 IDEA 都修好之后正常情况下问题已经消失。但还有一类场景是JDK 是 17环境也对报错却变成别的形态或者仍然顽固。这时候要检查 maven-compiler-plugin 本身。maven.compiler.release这个属性不是所有 compiler 插件版本都认。老项目如果父 POM 里显式把 compiler 插件锁在 2.x 或 3.1 这类远古版本即使 Maven 跑在 JDK17 上插件也可能不会正确读取release属性或生成的 javac 命令不符合预期。建议直接在buildplugins里锁一个较新的插件版本plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.11.0/version /plugin同时用属性统一编译目标properties maven.compiler.release17/maven.compiler.release /properties我推荐 3.11.0 的原因是它对release属性支持得很完整配 JDK17、JDK21 都没问题。如果项目还在用 Java8 目标也可以把 release 改成 8比如--release 8语法和 API 都按 Java8 来。锁版本之前先看实际生效的配置mvn help:effective-pom effective-pom.txt打开这个文件搜maven-compiler-plugin能看到最终使用的插件版本这比凭记忆猜准确得多。4.4 最后验证用一条命令确认端到端跑通全部改完后建议按这个顺序验证先写一个最小测试类public class Hello { public static void main(String[] args) { System.out.println(JDK17 OK); } }命令行手动编译一次javac --release 17 Hello.java java Hello这一步直接验证当前终端的 javac 是否支持--release 17。如果这条命令能过说明环境没问题剩下的就是 Maven 链路。再执行mvn clean compile如果项目还是报错加-X打开调试日志mvn clean compile -X mvn-debug.log在日志里搜javac或--release能看到 Maven 实际传给 javac 的完整参数以及它启用了哪个 java 可执行文件。这一步往往能让隐藏的 fork 配置现形。5. 同类坑的变种release 混用、Gradle 与 CI 环境5.1 release 和 source/target 混用会引发新的冲突修好环境之后另一个高频问题浮出水面pom 里既要maven.compiler.release17又保留老项目的maven.compiler.source和maven.compiler.target。JDK17 的 javac 明确规定--release不能和--source/--target同时使用。一旦同时出现报错是error: option --source cannot be used together with --release所以升级项目时正确做法是删掉 source/target 两个属性只保留 release。它一个参数就同时约束了语法、字节码和 API 可见性。这也是从 JDK8 迁移到 17 时顺手做掉的整理工作。这里多说一句团队里如果还有人用 JDK8 跑这个 pommaven.compiler.release17会让 JDK8 的 javac 直接报“无效的标记”——因为 JDK8 不认这个参数。所以项目统一了 JDK17 之后这种报错会从“跑不了的 Maven 环境”变成“拒绝人人都有 JDK17”的团队约束本质是好事。5.2 Gradle 和 CI 里一模一样的版本错位Gradle 项目也会有相似的错误报错的字符串可能不太一样但本质还是版本错位。Gradle 里通常会写compileJava { options.release 17 }或者用 toolchainjava { toolchain { languageVersion JavaLanguageVersion.of(17) } }toolchain 是自动选 JDK不需要用户手动设置 JAVA_HOME。但如果 Gradle 版本太老比如 6.x它对 Java17 的支持就是缺失的编译 JDK17 代码会失败或者行为异常。建议 Gradle wrapper 升到 7.3 以上用 8.x 更省心。同类排查思路不变先看gradle -v里的 JVM 版本再看项目 toolchain 指定版本是否匹配。CI 上更常见的是“本地好好的流水线一跑就报”。原因通常是流水线镜像里 Maven 默认 Java 是 8或者 setup-java action 设置了 17但后面某个步骤又把 PATH 里的 java 换掉了。CI 的 Dockerfile 里最好显式固定 JDK 路径并且在执行构建前打印一次三连版本java -version javac -version mvn -v这一步放到流水线日志里比事后翻历史构建记录省事太多。5.3 从根源上减少这类环境漂移的三个习惯第一每次切换 JDK 后第一件事不是打开 IDE而是跑一遍java -version javac -version mvn -v。十秒钟就能发现版本错位省掉后面半小时的排查。第二pom 或 build.gradle 里只写 release不写 source/targetMaven 项目明确锁住 maven-compiler-plugin 版本。让编译参数来源单一化别给“属性相互覆盖”留机会。第三团队项目里用.sdkmanrc、Maven Wrapper 或者统一安装脚本管理 JDK不要靠每个人手动改环境变量。新同事入职配环境时少走弯路线上构建也更稳定。我自己第一次遇到这个错时当时还没意识到 javac 和 java 可能来自不同 JDK爬了半天 pom。后来养成了“先把执行链路每一环的版本打印出来”的习惯绝大多数编译期怪问题都能在两条命令之内定位。无效的标记: --release这个报错看着唬人其实只是在替你大喊你编译用的 JDK 不是你想象的那个。
)
