Maven 的 source、target、release：字节码兼容不等于 API 兼容

target已经设成8，javap也显示major version: 52，为什么代码里还能调用 Java 11 才提供的String.isBlank()？

因为类文件格式和类库 API 是两项检查。先把这个反例编译出来，再回到 Spring Boot 的 POM 看配置，几个属性的作用就清楚了。

先看一个能通过编译的反例

保存为src/ApiTrap.java：

publicclassApiTrap{publicstaticvoidmain(String[]args){System.out.println(" ".isBlank());}}

本次使用 OpenJDK21.0.2+13-58。在命令行执行：

javac-encodingUTF-8-source8-target8-dout/source-target src/ApiTrap.java javap-verbose-classpathout/source-target ApiTrap

编译成功，但伴随选项和引导类路径相关警告。javap的结果同时包含：

major version: 52 java/lang/String.isBlank:()Z

52对应 Java 8 的类文件格式；后面那条方法引用却指向String.isBlank()。编译器当前能看到 JDK 21 的类库，因此找得到这个方法。-source 8限制语言规则，-target 8指定输出格式，它们没有自动把可见类库换成 Java 8。

现在只改编译选项：

javac-encodingUTF-8--release8-dout/release8 src/ApiTrap.java

这次编译失败，实际诊断中出现：

错误: 找不到符号 System.out.println(" ".isBlank()); ^ 符号: 方法 isBlank() 位置: 类 String

--release 8同时约束对应的语言规则、目标类文件格式和所能使用的该版本平台 API。它在编译时发现了越界调用。javac 的选项说明定义了这三项约束。

再把--release改为11：

javac-encodingUTF-8--release11-dout/release11 src/ApiTrap.javajava-cpout/release11 ApiTrap

相同代码可以编译，输出的 class major 为55。这份类在本次 JDK 21 上运行输出true。Java 8 运行时没有在这里执行；前两项证据已经足够说明：一个 Java 8 格式的 class，仍然可能引用 Java 8 不存在的方法。

图1：同一份isBlank源码的三组编译结果。major52只说明class格式；release8在编译阶段拒绝API越界，release11产物在本次JDK21运行。

在 Maven 中，把这个约束交给编译插件

下面是一个可单独运行的 POM，代码按 Maven 目录放到src/main/java/ApiTrap.java。它故意把目标设为8，用来重现上面的 API 拒绝：

<projectxmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><groupId>example.fixture</groupId><artifactId>compiler-release-check</artifactId><version>1.0-SNAPSHOT</version><properties><maven.compiler.release>8</maven.compiler.release><project.build.sourceEncoding>UTF-8</project.build.sourceEncoding></properties><build><plugins><plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-compiler-plugin</artifactId><version>3.16.0</version></plugin></plugins></build></project>

可直接调用指定版本的编译目标：

mvn org.apache.maven.plugins:maven-compiler-plugin:3.16.0:compile

本次 Maven 为3.9.12。在各自全新、没有旧 class 的两个实验项目里，release=8因isBlank()编译失败；release=11的构建成功。验证使用独立 settings、用户目录和本地仓库，没有执行install或deploy。

日常项目通常通过mvn clean verify做干净构建和验证。改完编译基线，应确认日志确实重新编译了源码；只看到BUILD SUCCESS还不够。本次复跑一个已有输出目录时，就曾看到Nothing to compile，随后改用每组全新目录做差异验证，避免让上一轮 class 掩盖结果。

对于 JDK 9 及以上的构建，优先用maven.compiler.release表达目标平台。JDK 8 自身不支持javac --release；较新的 Compiler Plugin 对在 JDK 8 下使用release属性有兼容处理，仍应按实际插件版本核对。Maven 的目标 Java 版本指南同时说明了这些条件，不能把一个属性片段当作所有构建环境通用的保证。

java.version 有没有作用，要看谁引用它

java.version不是 Maven 自动识别的“切换 JDK”开关。一个普通 POM 里，即使写了这个名字，也要有父 POM、插件或其他配置引用它，才会产生对应效果。

在继承spring-boot-starter-parent的项目中，这条引用是明确存在的。比如 3.5.16 的父 POM 将maven.compiler.release设为${java.version}。沿用这套父配置时，通常只需要覆盖一个来源：

<properties><java.version>17</java.version></properties>

如果项目只是在dependencyManagement中导入spring-boot-dependencies，它得到的是依赖版本管理，不会因此继承 starter parent 的插件管理和全部属性关系。这时应显式管理编译插件及maven.compiler.release。两种接法的差异，见 Spring Boot 的 Maven 配置说明。

所以，没必要为了“保险”把java.version、source、target、release全部写一遍。一处后来改成 21，另一处还停在 17，反而会增加排查成本。先确认当前父配置如何传值，再保留能表达项目目标的配置。

镜像构建也需要区分。spring-boot:build-image会结合编译目标配置及所选 builder/buildpacks 处理运行时 Java 版本，也允许专门覆盖；不能把它简化为“只要有 java.version 就会拉取对应基础镜像”。build-image 的说明列出了这条处理路径和覆盖入口。

图2：沿父POM引用找到编译目标。只导入BOM不会继承这条父配置链；release表达目标平台，实际JDK仍由构建环境和Toolchains等决定。

最后核对运行时与依赖的最低要求

mvn -version可以看到运行 Maven 的 Java 版本。若配置了 Toolchains，实际编译器还可能来自另一套 JDK；release只表达编译目标，不会替你安装或切换编译器。Maven Toolchains解决的是后一个问题。

release也不会把依赖重新编译成低版本。上面的 Java 8 例子是独立 Java 项目，用它说明 API 检查；不能据此把现代 Spring Boot 应用降成 Java 8。比如 Spring Boot 3.5 的系统要求明确要求至少 Java 17，框架本身的要求仍然成立。

排查部署异常时，可以沿两条线继续：UnsupportedClassVersionError先核对报错类的 class major 与运行时版本；NoSuchMethodError还要核对实际加载的类和依赖版本，不能只盯着source/target。缺失的方法可能来自 JDK API 越界，也可能来自第三方依赖冲突。

POM 把编译意图写清楚，干净构建检查实际产物，目标运行环境再验证依赖和行为。这几个检查各自有范围；release能把平台 API 错用提前到编译阶段，却不能替代部署验证。

2026-11-02 修订：补充 JDK/Maven 对照实验，明确 Spring Boot 父 POM 与 BOM 的差异，修正 java.version 和镜像构建关系的概括，并补充增量编译及依赖兼容边界。