17370845950

Java 17+ JDK 不再提供独立 JRE，java 命令直接来自 JDK/bin；JAVA_HOME 必须指向 JDK 根目录而非 bin，旧版 JRE 路径、rt.jar/tools.jar 引用及未适配模块系统的反射调用将导致运行或编译失败。

Java 17+ 的 JDK 安装不再提供 JRE，java 命令直接来自 JDK 自带运行时

从 JDK 14 开始，Oracle 就移除了独立 JRE 下载；到 JDK 17（LTS）及后续版本（如 21、22），JDK 安装包默认只含 bin、lib、conf 等目录，没有 jre 子目录。这意味着：

• java、javac、jar 全部位于 JDK_HOME/bin，无需额外配置 JRE_HOME
• 旧项目若硬编码了 JRE_HOME 环境变量（比如某些 IDE 启动脚本或 CI 配置），会报 Command not found 或路径不存在错误
• Spring Boot 3.x 默认要求 JDK 17+，若仍用 JDK 8 的 JRE/bin/java 启动，会因模块系统缺失而抛 java.lang.NoClassDefFoundError: java/sql/SQLException 类似错误

JAVA_HOME 必须指向 JDK 根目录，不是 bin 目录

常见误操作：把 JAVA_HOME 设为 /path/to/jdk-17.0.1/bin，导致 javac 找不到 tools.jar（已废弃）或模块描述符，实际编译失败。

• 正确写法：JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-17.0.1.jdk/Contents/Home（macOS）或 C:\Program Files\Java\jdk-17.0.1（Windows）
• 验证方式：运行

  echo $JAVA_HOME && $JAVA_HOME/bin/java -version

  ，输出应为 JDK 版本而非报错
• IDE（如 IntelliJ）中需在 Project Structure → SDKs 里重新添加 JDK 路径，不能复用旧的 JRE 配置

模块系统（java.base 等）启用后，--add-modules 和 --add-opens 成为高频参数

JDK 9 引入模块系统，JDK 17+ 默认严格限制反射与内部 API 访问。很多老框架（如 Hibernate 5.4、Log4j 2.16 之前）会因 java.lang.reflect.InaccessibleObjectException 崩溃。

• 典型修复参数：

  --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED

• Spring Boot 2.7+ 推荐用 --add-modules java.se.ee（仅限 JDK 17，JDK 21 已移除该聚合模块）
• Gradle 构建中需在 build.gradle 中显式配置：

  java { toolchain { languageVersion = JavaLanguageVersion.of(17) } }

  ，否则 javac 可能默认用 1.8 源码级别

旧版 rt.jar 和 tools.jar 彻底消失，依赖它们的构建脚本会直接失败

如果你的 CI 脚本或 Ant 配置里写了 rt.jar 路径（如 ${JAVA_HOME}/jre/lib/rt.jar）或显式引用 tools.jar，JDK 17+ 运行时会报 FileNotFoundException。

• 替代方案：所有标准类现在由 java.base 等命名模块提供，可通过 java --list-modules 查看
• 自定义类加载器若曾依赖 sun.misc.Launcher.getBootstrapClassPath()，需改用 ModuleLayer.boot().modules() 获取启动模块
• Maven 插件如 maven-compiler-plugin 若未声明 17 和 17，编译产物可能不兼容新 JVM

JDK 版本升级不是换 ZIP 包那么简单——模块边界、启动参数、环境变量语义都变了。最容易被忽略的是：旧构建工具链里那些“理所当然”的路径硬编码和反射调用，在 JDK 17+ 下不是警告，是直接中断。