JDK目录结构变化：8到9+的差异解析

JDK 9 引入的模块化系统彻底重构了运行时结构——取消独立 JRE、废弃 rt.jar、启用 jrt:// 协议访问系统模块，并对 sun.* 等内部 API 实施强封装，导致 IDE 识别失败、资源加载异常、反射调用崩溃、模块解析报错等一系列“看似升级成功、实则处处报错”的兼容性陷阱；真正阻碍迁移的往往不是目录路径变化，而是深埋在构建工具、IDE 插件、第三方库甚至自定义类加载器中的隐式依赖，唯有借助 java --list-modules 和 jdeps 等原生诊断工具穿透表象，才能高效定位并解决这些静默失效的底层链路问题。

为什么 JDK 9 的 bin 目录里找不到 javac.exe？

不是找错了，是它还在——但路径和依赖变了。JDK 9 开始彻底取消了独立的 JRE 子目录，jre 被合并进 JDK 主目录，同时 bin 下的工具不再默认携带完整运行时环境。

• JDK 8 的典型结构是：JDK8\bin\javac.exe + JDK8\jre\bin\java.exe，两个运行时可分离
• JDK 9+ 的结构扁平化：JDK9\bin\javac.exe 和 java.exe 都在同一个 bin 下，且它们启动时直接从模块化运行时映像（jrt-fs.jar）加载类，不再依赖 rt.jar
• 如果你用 IDE（如 Eclipse）配置 JDK 时卡在“JRE not found”，大概率是因为它仍按 JDK 8 逻辑去扫描 jre/lib/rt.jar，而该文件在 JDK 9+ 中已不存在

jrt:// 是什么？为什么 ClassLoader.getSystemResource() 在 JDK 9+ 里返回 jrt: URL？

这是 JDK 9 引入的新型资源访问协议，用于读取模块化运行时映像（即内存中压缩的系统模块集合），替代原先的 rt.jar 文件路径访问方式。

• 以前写 ClassLoader.getSystemResource("java/lang/Object.class") 返回的是 jar:file:///.../rt.jar!/java/lang/Object.class
• 现在返回类似 jrt:/java.base/java/lang/Object.class —— 这个 URL 不能用 File 解析，也不能直接 new URL(...).openStream()，必须用 Path.of(URI) 或 Files.readAllBytes() 配合 FileSystems.getFileSystem(URI)
• 自定义类加载器、热部署框架（如 Spring Boot DevTools）、或手动读取 JDK 内置资源的工具，若硬编码解析 jar: 协议，会在 JDK 9+ 上抛 IllegalArgumentException 或静默失败

为什么把 JDK 8 的项目切到 JDK 9 后，sun.misc.BASE64Encoder 突然报 NoClassDefFoundError？

这不是删了，是“强封装”开始了。JDK 9 默认禁止反射访问非 public 的内部 API，哪怕你只是 Class.forName("sun.misc.BASE64Encoder")，也会在类加载阶段被拦截。

• 该类在 JDK 8 是公开可用的“事实标准”，但从未属于 Java SE 规范；JDK 9 起被划入 jdk.unsupported 模块，且默认不可见
• 临时解法：启动参数加 --add-modules jdk.unsupported，但仅限过渡；长期必须改用 java.util.Base64（JDK 8u131+ 已 backport）
• 更隐蔽的坑：某些老版 Apache Commons Codec、Log4j 1.x、甚至早期 Hadoop 客户端会悄悄反射调用 sun.* 类，不升级依赖库的话，光换 JDK 就会导致运行时崩溃

IDE 报 “Module java.base not found” 或 “Unable to make progress with module resolution” 怎么办？

这是模块系统对传统 classpath 的“礼貌性拒绝”。JDK 9+ 启动时若检测到未声明模块描述符（module-info.java）的代码，会自动进入“unnamed module”模式，但部分 IDE 插件或构建脚本仍试图强制解析模块依赖图。

• Eclipse Oxygen 及更早版本对 JDK 9 模块支持不完整，建议至少升级到 2018-09 或更高；IntelliJ IDEA 2018.2+ 对模块感知更稳
• Maven 用户注意：maven-compiler-plugin 必须 ≥ 3.8.0，并显式配置 9 或 9，否则编译输出仍是 classfile version 52（JDK 8），导致模块信息丢失
• 最常被忽略的一点：即使不写 module-info.java，只要用了 java.xml.bind（JAXB）这类在 JDK 11 中被移除的模块，JDK 9 编译能过，运行时却可能因模块冲突失败——因为 JDK 9 还带 JAXB，但默认不导出给 unnamed module

理论要掌握，实操不能落！以上关于《JDK目录结构变化：8到9+的差异解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！