★ FEATURED ARTICLE 1. 这个警告到底在说什么从 javac 的 source/target 参数说起如果你用 IntelliJ IDEA 跑过 Maven 项目大概率在 Build 或 Run 窗口里见过这么一行黄字Warning:java: 源值 1.5 已过时, 将在未来所有发行版中删除 Warning:java: 目标值 1.5 已过时, 将在未来所有发行版中删除很多人第一反应是我明明装了 JDK 8/11/17怎么还在用 1.5然后去改 IDEA 的 Project SDK改完发现警告还在。这个现象背后其实牵扯到三层配置Maven 编译插件自己的 source/target、IDEA 从 pom 推导出来的模块语言级别、以及 IDEA 编译器实际传给 javac 的参数。三者只要有一处没对齐警告就会冒出来。先把概念说清楚。javac有两个关键参数-source和-target。-source决定编译器按哪个版本的语法规则来解析你的代码比如你用 JDK 17 编译但-source 8那 JDK 9 之后的新语法如var、文本块就不让你用-target决定生成的字节码版本号是多少也就是 class 文件里那个 major version它决定了这个 class 能被哪个版本的 JVM 加载。1.5 对应的就是 Java 52004 年发布的版本字节码 major version 是 49。那为什么默认会变成 1.5这就要说到 Maven 的maven-compiler-plugin。这个插件在很老的版本里如果你不显式配置source和target它会用一个非常保守的默认值。早期插件默认就是 1.5后来改成 1.6再后来在 3.8 以后的版本里才逐步要求你显式声明或者跟随maven.compiler.release。所以只要你的 pom 里没有明确写编译版本或者插件版本比较老javac 就会收到-source 1.5 -target 1.5于是警告出现。这里有个容易被忽略的点警告本身不影响编译结果代码照样能跑。但它是个信号说明你的构建配置处于未定义状态一旦升级 JDK 或者换机器很可能直接编译失败。而且从 JDK 12 开始-source 6及以下已经被彻底移除JDK 20 之后连-source 7都不支持了。所以这个警告不是看着烦的问题是迟早要炸的雷。提示判断当前实际生效的编译版本最直接的办法是在 IDEA 的 Build 输出里找-source和-target参数或者用mvn -X compile看 debug 日志里传给 javac 的完整命令行。2. 为什么改了 IDEA 的 SDK 还是没用配置的优先级链路这是踩坑最多的地方。很多人打开File → Project Structure → Project把 Project SDK 改成 17Language level 改成 17然后重新运行警告依旧。原因在于 IDEA 对 Maven 项目有一套导入时推导的机制它并不完全听 Project Structure 里的设置。具体来说IDEA 在导入 Maven 项目时会读取 pom 里的编译配置然后把它映射到模块的 Language Level 上。如果 pom 里没有配置IDEA 会用一个默认值老版本 IDEA 默认就是 5 或 6。而真正编译时IDEA 又可能走两条路一是用自己的编译器javac 包装二是委托给 Maven。走哪条路取决于Settings → Build → Build Tools → Maven → Runner里是否勾选了 Delegate IDE build/run actions to Maven。如果没勾选IDEA 用自己的编译器那它用的是模块 Language Level如果勾选了走 Maven那用的是 pom 里 compiler plugin 的配置。两条路的配置源不同所以你会看到改了 A 处B 处还在报的诡异现象。我整理了一张对照表把常见的配置位置和它的实际作用范围列出来配置位置作用对象是否影响 javac 参数常见误区pom 中 maven-compiler-plugin 的 source/targetMaven 命令行编译是只改这里IDEA 不 delegate 时无效pom 中 properties 的 maven.compiler.source/target同上插件会读取是属性名写错如 compiler.source不生效IDEA Project Structure → Project → Language levelIDEA 编译器是IDEA 编译时改了但模块级别没跟着变IDEA Project Structure → Modules → Sources → Language levelIDEA 编译器是每个模块要单独改容易漏Settings → Compiler → Java Compiler → Target bytecode versionIDEA 编译器是这里优先级很高容易被忽略Settings → Maven → Runner → Delegate to Maven决定走哪条路间接勾选后前面的 IDEA 设置全部失效看明白这张表你就知道为什么改了一处没用了。正确的做法是以 pom 为唯一事实来源让 IDEA 去跟随 pom而不是在 IDEA 里手动改一堆地方。具体操作是在 pom 里显式声明编译版本然后在 IDEA 里右键 pom → Maven → Reload Project让 IDEA 重新推导模块级别。这样无论走哪条编译路径参数都是一致的。还有一个隐藏的坑多模块项目里父 pom 和子 pom 的关系。如果父 pom 里配了maven.compiler.source子模块默认继承但如果某个子模块自己又声明了一遍就会覆盖。排查时要顺着模块树一层层看别只盯着报错的那个模块。3. 三种主流修法从最推荐到最将就针对这个警告社区里流传着好几种改法但它们的正确程度差别很大。我按推荐度从高到低说三种并解释每种背后的逻辑。3.1 用 maven.compiler.release 一步到位首选从 JDK 9 开始javac 引入了一个新参数--release它能同时控制 source、target 和 bootclasspath也就是编译时引用的 JDK API 版本。用--release 17比单独写-source 17 -target 17更严谨因为它能防止你误用高版本 JDK 里才有的 API 却编译到低版本目标上。在 pom 里这样写properties maven.compiler.release17/maven.compiler.release project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties或者更显式地配置插件build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.13.0/version configuration release17/release /configuration /plugin /plugins /build注意release参数要求编译用的 JDK 本身不低于目标版本。也就是说你要编译到 17本机 JDK 至少得是 17。这个约束是合理的避免了用低版本 JDK 假装编译高版本的荒唐情况。3.2 传统 source/target 组合兼容老项目如果你的项目还在用 JDK 8 甚至更早或者构建环境不支持--release那就用经典的 source/targetproperties maven.compiler.source1.8/maven.compiler.source maven.compiler.target1.8/maven.compiler.target /properties这里有个细节1.8 和 8 是等价的但写1.8更符合历史习惯写8在新版本插件里也认。不过要注意source 和 target 最好保持一致混用比如 source 8、target 11虽然语法上允许但会产生一些边界问题比如你用了 JDK 8 的语法却生成 11 的字节码运行时如果环境是 8 就会UnsupportedClassVersionError。3.3 只在 IDEA 里改最不推荐仅应急如果你只是临时想消掉警告不想动 pom比如这是别人的项目你只是本地跑一下可以在 IDEA 里改File → Project Structure → Project把 Language level 设为对应版本File → Project Structure → Modules逐个模块把 Sources 标签下的 Language level 也改掉Settings → Build, Execution, Deployment → Compiler → Java Compiler把 Target bytecode version 改成一致。但这么做的问题很明显配置没有沉淀到项目里换台机器、换个同事、CI 上跑警告照样出现。所以这只适合临时验证不适合作为最终方案。注意无论用哪种方式改完 pom 后一定要在 IDEA 里执行 Maven Reload否则 IDEA 缓存的模块级别不会更新你会以为改了没用。4. 一次完整的排查实录从警告到彻底消除光讲理论不够我把一次真实的排查过程完整还原出来你可以照着这个链路走一遍。现象某次拉下一个老项目mvn clean compile时刷出一屏源值 1.5 已过时IDEA 里 Run 也是同样警告。第一步确认实际参数。执行mvn -X compile 21 | grep -A2 Command line options看到 javac 收到的确实是-source 1.5 -target 1.5。这一步很关键它排除了只是 IDEA 显示问题的可能确认是 Maven 层面传下去的。第二步看 pom 有没有配置。打开 pom发现build里只有一个空的plugins没有任何 compiler 配置properties 里也没有maven.compiler.*。这就解释了为什么是默认值——插件用了它自己的默认。第三步确认插件版本。执行mvn help:effective-pom | grep -A5 maven-compiler-plugin发现生效的是 3.1 版本这个版本的默认 source/target 就是 1.5。到这里根因清楚了老插件 无显式配置 默认 1.5。第四步动手修。在 properties 里加上maven.compiler.release项目实际用 JDK 11所以写 11同时把 compiler plugin 升到 3.13.0。这里为什么两个都做因为光加 release 属性老插件 3.1 可能不认这个属性release 支持是后来才加的所以插件版本也得跟上。第五步验证。重新mvn clean compile警告消失。再mvn -X compile看参数变成了--release 11。然后回 IDEA右键 pom → Maven → Reload再 Run警告也没了。第六步检查模块级别。Reload 之后打开 Project Structure确认各模块 Language level 已经自动变成 11。如果没变说明 IDEA 的推导没生效需要手动同步一次。整个链路走下来核心思路就是先定位参数从哪来再找到配置源头改源头而不是改表象最后验证参数真的变了。很多人卡在第三步只改 IDEA 不改 pom或者只改 pom 不 reload都会导致改了没用的错觉。5. 那些年一起踩过的坑六个高频误区这个警告看似简单但衍生出来的坑特别多。我挑六个最常见的说一下每一个都是真实踩过的。误区一以为升级 JDK 就能解决。JDK 版本和编译 source/target 是两码事。你装了 JDK 17但 pom 里没配插件照样传 1.5 给 javac。JDK 只是用哪个编译器source/target 是按什么规则编译。误区二把maven.compiler.source写成maven.compiler.source.version。属性名必须精确写错了 Maven 不报错只是静默忽略然后你继续看到 1.5 警告还以为是别的原因。误区三多模块项目只改父 pom 的子集。父 pom 配了但某个子模块的 pom 里parent指向的不是这个父或者子模块自己覆盖了属性就会导致部分模块正常、部分模块报警。排查时用mvn help:effective-pom -pl 模块名看每个模块实际生效的值。误区四IDEA 的 Delegate to Maven 勾选状态来回变。这个选项决定了走哪条编译路径团队里如果有人勾了有人没勾就会出现我这儿好的你那儿报错的玄学问题。建议团队统一要么全 delegate 到 Maven要么全用 IDEA 编译但保证 pom 配置完整。误区五改了 pom 不 reload。IDEA 会缓存 Maven 项目的模型pom 改了不 reloadIDEA 用的还是旧模型。这个坑太常见了以至于我养成了改完 pom 先 reload 再说话的习惯。误区六忽略 Lombok、MapStruct 等注解处理器的版本兼容。有时候你改了编译版本警告没了但注解处理器开始报错。这是因为这些工具对 source/target 有要求升级编译版本时要同步检查它们的版本。比如老版本 Lombok 在 JDK 17 下可能有问题需要升到较新版本。提示如果排查半天没头绪用mvn help:effective-pom输出完整生效的 pom搜索source、target、release三个关键词基本能定位到问题所在。6. 顺手把编译配置做扎实几个值得养成的习惯警告消掉只是起点真正让项目构建稳定的是把编译配置当成一件正经事来做。分享几个我这些年养成的习惯。第一编译版本写进 properties不散落在插件配置里。这样升级时只改一处而且 IDEA 对 properties 形式的maven.compiler.*识别得更好能自动同步模块级别。插件配置里写release虽然也行但 IDEA 的推导不如 properties 灵敏。第二显式声明 compiler plugin 版本。不写版本Maven 会用默认绑定版本不同 Maven 版本默认的插件版本还不一样导致构建结果不可复现。写死一个稳定版本比如 3.13.0团队和 CI 行为一致。第三source/target/release 三者不要混用。要么全用 release要么全用 sourcetarget。混用会出现release 覆盖了 source/target或者source/target 又覆盖回来的混乱具体谁赢取决于插件版本非常难排查。第四把project.build.sourceEncoding一起设了。编码问题和编译版本问题经常一起出现尤其是中文注释乱码。设成 UTF-8 是基本操作能省掉很多为什么我的中文变问号的困惑。第五CI 上加一道检查。在流水线里跑一次mvn -X compile并 grep 一下-source 1.5或--release如果发现版本不对直接 fail。这样能防止有人本地改了没提交或者新加的模块漏配。第六升级 JDK 时同步检查编译目标。很多人升级了运行环境 JDK却忘了改编译目标结果编译出来的 class 版本和运行环境不匹配。养成升 JDK 必查 pom 编译配置的习惯。最后说个我自己的体会这个 1.5 警告之所以烦人不是因为它难解决而是因为它暴露了项目构建配置的欠债。一个连编译版本都没显式声明的项目往往在其他构建细节上也含糊。所以每次看到这个警告我都会顺手把整个build段检查一遍把该显式的地方都显式掉。改完之后不仅警告没了整个构建的可预测性也上了一个台阶。
阅读完成 · 觉得有帮助？
