必须更新Maven插件和配置而非仅Maven本身，否则编译等操作易失败；典型信号是“release不被识别”，因旧版maven-compiler-plugin（如3.6.2）不支持JDK11+的-release参数，需升级至3.8.1+并配置<release>11</release>。

需要，但不是“必须同步更新 Maven 本身”，而是必须更新 Maven 的插件和配置，否则编译、测试、打包大概率失败或行为异常。

mvn compile 报错 “release” 不被识别

这是最典型的信号：Maven Compiler 插件版本太老，不支持 JDK11+ 的 -release 参数。

• JDK9 引入 -release（如 -release 11），它比 -source/-target 更严格，能避免意外调用内部 API
• 旧版 maven-compiler-plugin（如 3.6.2）根本不认识 <release> 配置项，直接报错
• 正确做法是升级插件到 3.8.1+，并在 pom.xml 中写成：

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.1</version>
    <configuration>
      <release>11</release>
    </configuration>
  </plugin>

mvn test 失败，Jacoco 或 Surefire 报 ClassNotFoundException

不是 JDK 升级本身的问题，而是插件依赖了已移除的 JDK 内部类（比如 com.sun.*）或用了过时的字节码处理逻辑。

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• jacoco-maven-plugin 在 0.8.3 之前不兼容 JDK11；maven-surefire-plugin 在 3.0.0-M5 之前无法启动 JUnit5 测试引擎
• 错误示例：java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException —— 这说明你还没补上 Jakarta XML Binding 依赖，但插件本身也得先能跑起来
• 关键点：这些插件的二进制包是编译在特定 JDK 上的，它们的字节码解析器、ASM 版本、反射调用路径都可能随 JDK 演进而断裂

mvn versions:display-dependency-updates 查不到新版本

不是命令失效，而是插件版本太低导致元数据解析失败或忽略 Jakarta 命名空间迁移后的坐标。

• versions-maven-plugin 2.7 以下版本对 jakarta.* 坐标（如 jakarta.servlet:jakarta.servlet-api）识别不稳定
• 推荐使用 2.17.1 或更高版，它能正确解析 Spring Boot 3.x / Jakarta EE 9+ 的依赖树
• 执行前确认本地仓库没卡在中间状态：mvn clean + 删除 ~/.m2/repository/org/codehaus/mojo/versions-maven-plugin/ 目录再重试

真正容易被忽略的是：JDK 升级后，Maven 的 MAVEN_OPTS 可能仍含 -XX:MaxPermSize 这类 JDK8 专属参数，JDK11+ 会静默忽略，但若项目里有大量 ASM 字节码操作，实际内存压力可能远超预期 —— 这类问题不会报错，只会表现为构建变慢、随机 OOM 或测试挂起。