怎么利用 JDK 9 之后的模块化路径覆盖（Patch Module）实现在不修改 Jar 包的前提下重写核心类-java教程-PHP中文网

--patch-module的真实作用是将指定目录或jar中的类文件视为目标模块（如java.base）的一部分优先加载，仅调整类加载顺序而不修改模块声明；它要求路径严格匹配、常需配合--add-opens使用，且在java 17+中受强封装限制更严。

怎么利用 jdk 9 之后的模块化路径覆盖（patch module）实现在不修改 jar 包的前提下重写核心类

不能直接“覆盖”核心类，但可以用 --patch-module 把你自己的类强行注入到目标模块的 classpath 之前，让 JVM 优先加载你的版本——这是唯一合规、可落地的替代方案。

它不是热替换，也不是字节码篡改，而是告诉 JVM：“请把这一堆 class 文件（或目录）当作 java.base（或其他模块）的一部分来加载”，并**在模块内包路径冲突时优先使用你提供的类**。它只影响类加载顺序，不改变模块声明本身。

常见错误现象：

加了 --patch-module java.base=patch/ 但类没生效 → patch 目录下没有对应包路径（如 java/lang/String.class 必须放在 patch/java/lang/）
启动报 java.lang.SecurityException: Prohibited package name → 尝试 patch java. 或 javax. 下的类，JVM 会直接拒绝（除非用 --add-opens + 启动参数绕过，但不推荐）
类被加载了，但反射调用失败 → 没加 --add-opens 开放目标包给你的模块

适用于三类情况：

注意：它不能用于 patch java.base 中被标记为 final 的类（如 String），因为 JVM 会校验签名；也不能 patch 已被 exports 限制的包，除非你同时用 --add-exports 解封。

假设你想 patch java.base 中的 java.time.format.DateTimeFormatter，用自己的实现替换：

java --patch-module java.base=patch/ \
     --add-opens java.base/java.time.format=ALL-UNNAMED \
     -cp app.jar MyApp

说明：

--patch-module java.base=patch/：把 patch/ 目录下的类视为 java.base 模块的一部分
--add-opens java.base/java.time.format=ALL-UNNAMED：允许未命名模块（即你的 app.jar）通过反射访问该包（否则 patch 后仍可能因封装限制失败）
如果 patch 的是服务提供者（如 java.sql.Driver），还需额外加 --add-modules java.sql

Java 17+ 默认启用强封装，--patch-module 的行为变得更保守：

JDK 17 起，--patch-module java.base 对 java.* 包的 patch 会被静默忽略，除非加 --illegal-access=permit（已废弃）或改用 --add-opens + 自定义类加载器
模块化应用中，如果你的主模块是 com.example.app，而 patch 目标是 java.desktop，那么必须在 module-info.java 中显式 requires java.desktop;，否则 --patch-module 不生效
Maven/Gradle 构建时，--patch-module 只在运行时起作用，无法参与编译期校验——这意味着你 patch 的类在编译时不可见，所有引用都得靠反射或接口抽象