更新日志

6.0.24 2026-08-31

受保护的包现在带有一份由服务器签名的准入记录

加固了「哪些代码可以进入受保护进程」这道判断。包里受保护的类清单、classpath 准入清单和原生库准入清单，此前只靠包自身的加密来保护，因此有人一旦把包解开，就能把自己的 JAR 加进准入清单再重新封回去——他的代码就此进入受保护进程，对已经加载的一切拥有完整的反射访问权。现在这几份清单被一份只有授权服务器才能生成的签名覆盖，运行时在读取它们之前先验证这份签名，所以清单被改过的包、或者把别的包的记录复制过来的包，都不再能启动。加密时仍然只发出原来那一次授权请求，打包方式没有任何变化。
由于本次发布改动了保护相关的运行时二进制，已有的受保护应用需要用本版本重新编码，才能在更新后的运行时上运行。

6.0.23 2026-08-30

通过 JNI 访问受保护类的原生库现在能正常工作

修复了 usb4java（用于 KNX/Calimero USB 通信）、SWT 等通过 JNI 读写受保护类字段或调用其方法的原生库，在这些类被保护时无法工作的问题。此前 Protector4J 会对 JNI 的字段和方法查找隐藏受保护类，这同时也挡住了这些正当的框架库，逼你用 --exclude 把受影响的类留作不保护。这道拦截与加密本身已提供的保护重复、并不带来实际安全收益，因此已移除；这些库现在在类完全受保护的情况下也能正常工作，不再需要 --exclude。
由于本次发布改动了保护相关的运行时二进制，已有的受保护应用需要用本版本重新编码，才能在更新后的运行时上运行。

6.0.22 2026-08-26

打包含 JSP 的 Tomcat 应用现在能成功

修复了这样一个问题：WAR 里含 JSP 页面时，打包失败并报 ClassFormatError: Incompatible class format。Protector4J 在打包时会把 JSP 预编译成 servlet，这既需要一个 Java 编译器，也需要加载应用自己的标签处理类。此前这两件事都在 Protector4J 自己的进程里做——那里既没有编译器（随包运行时是纯 JRE），保护机制的类准入规则也不允许加载应用的类。现在这两步都改到一个标准 JDK 里执行，该 JDK 由 Protector4J 按需下载并缓存在本地，所以打包 JSP 应用不再要求机器上装有 JDK。首次打包会下载一次工具链（约 200 MB），之后直接复用缓存。

编辑运行时的安全配置不再导致受保护应用无法启动

修复了这样一个问题：运维编辑随包运行时的 conf/security/java.security 后，受保护应用起不来——比如为了注册安全 provider（PKCS#11/HSM 或 BouncyCastle）、禁用弱 TLS 算法、开启 FIPS 模式、或改 securerandom.source。运行时此前把解密绑定到了这个文件的确切内容，改动它就让受保护归档打不开、报一个看不懂的启动错误。而这个文件是 JDK 设计上就允许运维编辑的配置，改它也帮不了任何人绕过保护，所以绑它不增加安全、只留了个坑。
现在运行时身份只绑定保护性二进制——启动器和几个核心 native 库——这才是真正阻止受保护应用在被篡改的 JVM 上运行的东西；安全策略文件和一个内部能力标记不再是其中一部分。用正常方式编辑运行时的安全策略现在能工作了。由于运行时身份变了，已有的受保护应用需要用本次发布重新加密。

依赖 jar 里的大资源不再导致加密失败

修复了这样一个问题：受保护 Tomcat 包里的某个依赖 jar 含有大于 16 MB 的资源时加密失败——最常见的是 icu4j，它的 icudt*.dat 数据文件约 25–30 MB，很多企业库会间接依赖它。打包器此前把每个嵌套 jar 的每一个条目都按 16 MB 上限读进内存，可实际上只有类文件参与准入校验,于是一个大数据文件就让整个打包失败。现在打包器只读类文件和 manifest、其余资源不动,这类应用可以正常加密,内存占用也更小。

用 shade 打成 fat JAR 的 JxBrowser 桌面应用现在能加密了

修复了 --native-compat jxbrowser 在应用被打成单个 shade / assembly fat JAR 时报「no artifacts detected」的问题。扫描器此前只按 JxBrowser 独立依赖 JAR 的文件名来识别，而 shade/assembly 会把这些独立 JAR 摊平掉。现在它还会按内嵌 Chromium 归档的内容哈希来识别运行时——shade 会逐字节原样复制这个归档——因此同一批受信任的 native 库照样被授权，写到磁盘上的准入数据与独立 JAR 路径逐字节一致。

受保护类超过约 1300 个的应用现在能加密了

修复了应用受保护类超过约 1300 个时加密报个看不懂的「UTF8 string too large」的问题。受保护类名的完整清单此前被烤进生成的启动器、作为单个 class 文件字符串常量，而这个常量上限是 65535 字节。清单现在改成包里的一个资源、运行时读回来，受保护类的数量不再受那个上限约束；同时打包器在任何生成值逼近上限时会报一个清楚、能照做的错误。

6.0.21 2026-08-25

大型 Tomcat 应用和依赖很多的应用无法加密或无法启动

提高了 classpath 准入清单的容量上限。受保护的 Tomcat 包会为每个 WEB-INF/lib JAR 里的每个类记录一条准入条目，而这份元数据整体被限制在 4 MB——大约 21000 个类。规模更大的 Web 应用会撞到这个上限，并以 nested classpath metadata is too large 停下。现在上限提高到 64 MB，相关的每个 JAR、每个类的数量限制也按相同比例放大，因此有几万个类的常见企业应用可以正常加密。
编码器现在会在加密阶段就拒绝超出容量的包，并给出超了多少的提示，而不是先产出一个只有到启动时才失败的归档。普通 classpath JAR 的数量、受保护归档的数量这两项此前只由运行时检查，因此依赖很多的 Spring Boot separate 包、或者部署了很多 Web 应用的 Tomcat 底座，可能顺利加密却随后启动失败。
重写了运行时加载大型准入清单的方式，让启动保持快速。原先的逻辑随类数量的平方增长，遇到大型 Web 应用会让启动卡住好几分钟。五条 JDK 线都随本次修复重新构建：JDK 25、21、17 到 VLX 1.0.24，JDK 11 到 VLX 1.0.22，JDK 8 到 VLX 1.0.15。
修复同时涉及编码器和随包运行时，因此已有的受保护应用需要用本次发布重新加密才能获得修复。

业务代码全在依赖 jar 里的 Spring Boot 应用，加密后接口全 404

修复默认 p4jx-fat 布局下的一个问题：当 controller、配置、安全这些业务类不在 BOOT-INF/classes、而是在 BOOT-INF/lib 的依赖 jar 里时，加密后的 Spring Boot 应用一个接口都不提供。应用照常启动、服务器照常监听、日志无任何报错，但每个请求都返回 404、Spring Security 退回默认配置——因为 Spring 的组件扫描看不到依赖 jar 里的任何类：生成的类加载器只为 BOOT-INF/classes 的条目登记了包目录。这与加密无关，同样的布局无论加不加密都会挂。
现在 p4jx-fat 加载器会为每个 BOOT-INF/lib 的 jar 登记包目录，并通过与 Spring Boot 自身同形的嵌套 jar URL 暴露给框架，组件扫描于是能发现依赖 jar 里的 controller 和配置。用 --protect-lib 时，元数据桩改为留在重建后的依赖 jar 原位，不再投影进 BOOT-INF/classes。

6.0.20 2026-08-22

受保护应用随机崩溃，涉及全部受支持的 JDK 线

修复随包运行时的一处缺陷：受保护应用可能在启动后几分钟到一天之内随机终止。当 JIT 编译器丢弃优化代码、重建解释器栈帧时，运行时直接从内存读取方法调用指令的操作数而没有解密，再拿这个无意义的值去索引常量池缓存。用户报告的现象是 JVM 致命错误中出现 parameter_size；同一缺陷也可能在完全不报错的情况下写坏无关内存。热点代码被大量优化的应用最容易碰上。
针对同一类缺陷在五条 JDK 线上逐一排查，又找出五处读写受保护元数据时未先解码的地方。其中两处会让一项内部一致性检查随机终止 JVM，还有一处是类链接期的竞态，可能在类尚未准备完成时交出无效的常量池指针。这些问题在本次发布的运行时中全部修复。
修复位于随包运行时而非编码器，因此已有的受保护应用需要用本次发布重新加密才能获得修复。

`p4jx-fat` 布局下 Spring Boot 4 应用在 JDK 25 上无法启动

修复 p4jx-fat 布局按错误的 Java 版本解析多版本依赖的问题。打包器用的是命令行选定的运行时训练线——只传 --jre-home 时它会退回 21——而不是实际打包的那个运行时的版本。于是为 JDK 25 运行时打包时，META-INF/versions/22 及以上的条目全部被丢弃。配合 Spring Framework 7，这会丢掉只存在于 JDK 24 变体中的 ClassFileMetadataReaderFactory，导致所有 Spring Boot 4 应用启动时抛 NoClassDefFoundError。fat 与 separate 两种布局从未受影响，因为它们把依赖保留为普通 JAR 文件、由 JVM 自己打开。

命令行的 `encode` 命令恢复可用

6.0.19 在图形界面中把独立类库加密标记为开发中，同时也意外地在命令行阻断了 encode 命令。现已移除该阻断，encode 恢复为此前的行为。图形界面仍保留「开发中」角标，那一侧没有变化。

不再支持 Windows ARM64 目标平台

windows-aarch64 支持已撤销：图形界面不再提供该选项，--target-platform windows-aarch64 会被拒绝，不再为它生成 EXE 启动器，也不再发布对应的随包运行时。ARM 版 Windows 可以通过系统内置的模拟运行 windows-x64 包。当前受支持的目标为：Apple 芯片与 Intel 的 macOS、ARM64 与 x64 的 Linux、x64 与 x86 的 Windows。

6.0.19 2026-08-15

未登录账号加密时明确提示试用版有效期

未提供账号凭据时，CLI 的警告现在会明确说明：生成的受保护应用使用试用许可，仅能运行 7 天，并附上购买许可的地址 https://protector4j.com。此前的警告只提到「试用许可」，没有说明这对应用意味着什么。
GUI 在开始加密前会以对话框展示同样的提示，提供三个选择：购买、继续任务、取消任务。购买按钮打开的是当前所选服务器区域对应的购买页面，选择 .cn 区域的用户不会被带到 .com 站点。

支持从其它工具带参数启动 GUI

GUI 现在接受启动参数：p4j-ui [--task-file <file>] [<input-file>]。传入任务文件会走正常的导入流程，直达最终确认页。传入普通输入路径则预填进新任务：.war 自动进入 Tomcat 流程，.jar 停在应用类型选择页，因为一个 JAR 可能是 Java 应用、Spring Boot 应用或类库。这是为 IDE 插件等外部工具准备的对接入口；未知的横线参数会被忽略，不带参数启动 GUI 的行为与之前完全一致。

独立类库加密标记为开发中

独立类库加密在 6.x 线尚未就绪，现在明确标记出来：GUI 中对应的选择卡片置灰并带「开发中」角标，CLI 的 encode 命令会输出说明信息后退出，不再开始任务。该功能会在后续版本中提供。

6.0.18 2026-08-13

Spring Boot p4jx-fat 布局支持多版本 JAR

修复了 Spring Boot p4jx-fat 布局下多版本依赖只会加载到基础版本的问题。类加载器解包嵌套的 BOOT-INF/lib 依赖时，是按字面路径存放条目的，于是 META-INF/versions/ 下的类永远选不中，始终回落到基础版本。一个具体表现是：配合 Spring Framework 7.0.5 时，VirtualThreadDelegate 解析到的是基础版本的桩实现，而它无条件抛出 UnsupportedOperationException，因此在 JDK 25 上开启 spring.threads.virtual.enabled=true 的应用会启动失败。大量常用依赖都以多版本 JAR 形式发布，其它版本相关的代码路径同样受影响。
现在类加载器会在加载时解析多版本条目，按运行中的 JDK 挑出适用的最高版本；打包器构建 fat 资源索引时套用同一套规则，保证索引与加载器对「哪一份生效」的判断始终一致。另外两种布局 fat 与 separate 从未受影响，它们把依赖保留为普通 JAR 文件，由 JVM 自己打开。

6.0.17 2026-08-13

修复 Windows 上路径含非 ASCII 字符时加密应用无法启动

修复了在 Windows 上应用路径含有中文等非 ASCII 字符时，加密后的应用无法启动的问题。视路径在哪里被读错，启动会报归档错误 E816，或者表现为解密失败的 ClassFormatError。运行时打开归档和归一化路径都是按字节处理的，于是传统代码页里第二个字节恰好是 0x5C（反斜杠）的字符会被从中间劈开，后半个字节被当成了目录分隔符。GBK 里有大量常用汉字正好是这种编码。全部由 ASCII 字符组成的路径从未受影响。
Windows 上运行时现在会先按系统 ANSI 代码页把路径转成宽字符，再打开文件和计算运行时指纹——原厂 JDK 一直就是这么打开文件的。只改动了 Windows 分支，Linux 与 macOS 的行为与之前完全一致。五条 JDK 线都已带此修复重新构建：JDK 25、21、17 升到 VLX 1.0.22，JDK 11 升到 VLX 1.0.20，JDK 8 升到 VLX 1.0.13。

6.0.16 2026-08-10

修复 Windows 上打包 Linux 与 macOS 目标失败

修复在 Windows 上、目标平台为 Linux 或 macOS 时打包失败的问题。解压随包运行时会报 Failed to extract P4JX runtime，而实际上运行时已经正确解压完成。Windows 上创建符号链接需要提升权限，而 Linux 与 macOS 的运行时在 legal/ 下有一百多个符号链接——那些是 jlink 为了不重复存放而指向 java.base 的许可证文本。Windows 自带的 tar 命令把建不了链接当作警告处理，但仍然返回非零退出码，编码器据此判定为彻底失败，并把已经解压好的运行时删掉了。在 Windows 上打包 Windows 目标从未受影响，因为 Windows 运行时里根本没有符号链接。
归档处理不再依赖各平台的 tar 命令。编码器现在自己读取和解压 .tar.gz 运行时与 JavaFX 素材，因此在 Windows、Linux、macOS 上行为完全一致。文件权限（包括启动器的可执行位）取自归档本身，而不是宿主文件系统。Windows 上会跳过那些许可证符号链接：它们对运行时没有任何功能作用，也不参与运行时指纹，因此在 Windows 上加密的应用解密行为与以往完全相同。

6.0.15 2026-08-08

更新对话框修复

「有新版本」对话框现在以固定的合理尺寸打开，changelog 较长时不再撑满整个屏幕。
工具栏新增「检查更新」入口，随时都能检查新版本，不再只在启动时检查。

6.0.14 2026-08-07

字符串常量内联加密，现为默认

新增内联字符串保护模式：把加载字符串的 ldc 指令改写成对本类合成解密方法的调用，字符串常量的明文被彻底从常量池移除。明文在类加载时不再进入 SymbolTable，只有真正执行到那行代码时才出现在堆上，未用到的字符串始终保持密文。密文随类体一同携带，并受既有的逐方法加密保护——这是纯编码器侧的字节码变换：归档格式与运行时都不变，在所有受支持的 JDK 线上都无需更新运行时即可生效。
字符串保护现整合为一个选项、三种模式——无、普通加密（常量池 V72）、内联，且内联是所有应用类型（含 Tomcat）的默认值。已在普通 servlet、字符串 switch 业务逻辑、以及 JspC 预编译的 JSP servlet 类上端到端验证。命令行开关为 --encrypt-strings none|constant|inline，GUI 提供相同选项。
无法改写的方法——旧类文件格式的接口、逼近 64 KB 上限的方法、或罕见的序列化边界情形——会回退到普通的 V72 层，因此结果绝不弱于以往。

Spring Boot p4jx-fat 启动更快

纯 fat 布局的 Spring Boot 类加载器现在按需读取其嵌套资源索引，而非预先全部加载，减少大型 p4jx-fat 应用的启动开销。

从环境变量读取账号凭据

encode、javaapp、springboot、tomcat 命令及任务文件模式现在可以从 P4JX_ACCOUNT_EMAIL 和 P4JX_ACCOUNT_PASSWORD（或 P4JX_ACCOUNT_PASSWORD_MD5）读取账号邮箱与密码，仅在对应命令行选项缺席时使用，因此导出的任务文件不含凭据。

6.0.13 2026-08-05

修复使用 `javax.lang.model` 的受保护应用启动失败

修复受保护应用启动时抛出 NoClassDefFoundError: javax/lang/model/SourceVersion 的问题——这类应用的框架会引用 javax.lang.model API，最典型的是 Spring Data JPA，它的仓库 AOT processor 在容器初始化时会用到 SourceVersion。此前从裁剪运行时中移除的 java.compiler 模块现已重新纳入。它是纯 API 模块，不含编译器实现，因此 ToolProvider.getSystemJavaCompiler() 仍返回 null、jdk.compiler 仍然缺席——防护面没有任何变化。
JDK 17、21、25 的运行时重建为 VLX 1.0.21，JDK 11 重建为 VLX 1.0.19，都带上了恢复的 java.compiler 模块。JDK 8 不受影响，因为它没有模块系统、本就自带这些类。

6.0.12 2026-08-02

支持 JxBrowser 9，并修复受保护应用抛出 NullPointerException 时的崩溃

受保护应用现在可以内嵌 JxBrowser 9。--native-compat jxbrowser 从内置目录的九个版本（9.0.0 至 9.3.1）中选择一个，覆盖 Java 17、21、25 上的七个平台。运行时只会把线程 attach 权限授予所选版本已登记 SHA-256 的官方 IPC 库，并在线程真正 attach 时重新核对调用模块；命令行不接受路径、哈希或库名。在 macOS 26 上请使用 JxBrowser 9.0.1 或更高版本：TeamDev 在该版本修复了创建 Engine 时的 Chromium 崩溃，9.0.0 在普通 JDK 上同样会崩溃。
修复受保护应用抛出 NullPointerException 时出现 ClassFormatError 的问题。6.0.9 的修复按方法逐个屏蔽 JVM 的扩展 NPE 消息，事实证明并不彻底：该功能会按标准字节码文法解析方法体，而 P4JX 变换过字节码之后，没有任何按方法设置的标志能证明这次解析仍然有效。运行时现在无条件禁用扩展消息。异常类型、调用栈以及应用自己提供的消息都不受影响。JDK 17、21、25 的运行时重建为 VLX 1.0.20；JDK 11 不受此问题影响，保持 VLX 1.0.18，JDK 8 保持 VLX 1.0.12。
java -version 现在会显示 VLX 运行时版本，不必解包就能识别交付包里的运行时。
Windows EXE 的两个版本字段改为在打包开始前校验，不再跑到中途才失败。Windows 把每一段版本号存成无符号 16 位整数，因此以点分隔的一到四个数字每个都必须在 0 到 65535 之间；字段留空仍然表示 0.0.0.0。

6.0.11 2026-07-27

受保护应用的原生 Windows 启动器

Java App 打包、三种 Spring Boot 布局和 Tomcat 打包现在都可以选择生成原生 Windows EXE。Windows x64、x86 和 ARM64 均提供控制台与 GUI 启动器，原有启动脚本也会继续保留在每个交付包中。
CLI 和 GUI 新增 EXE 文件名、模式、图标及 Windows 版本元数据设置。多平台任务只会为选中的 Windows 目标生成 EXE；设置会保存在版本 2 的 p4j-task.yml 中，版本 1 的任务文件仍可读取。
纯 Win32 的 JExeKit 启动器已与交付包内的 vlxjre、精确 classpath 和 JVM 参数集成。启动 Java 前，启动器会拒绝逸出交付包范围的路径、通过重解析点进行的替换，以及不安全的 agent 或 boot classpath 选项。
JExeKit 模板只会以 AES-GCM 加密的 .jxt 资源嵌入，生成启动器时仅在内存中解密。每个生成的启动器都会为参数块添加 production 状态的 Ed25519 签名；图标、版本、manifest 和参数修改会在用户最后应用 Authenticode 签名前全部完成。

6.0.10 2026-07-27

更快且保持原始结构的 Tomcat 依赖加载

修复 Tomcat 启动严重变慢的问题：此前每加载一个类，都会重新读取受保护的整个 WEB-INF/lib 嵌套 JAR 并计算 Hash。VLX 1.0.17 现在对每个已密封的嵌套 JAR 只验证一次，在 VM 内缓存其已认证来源，并继续根据加密类索引逐一校验每个请求的类。
移除临时的 web-libs 解包和挂载变通方案。WEB-INF/lib/*.jar 继续保留在受保护的 .p4jx 归档内，维持原始 WAR 结构和应用隔离。JDK 11、17、21 和 25 的 VLX 1.0.17 运行时已覆盖 24 个受支持的平台组合；JDK 8 保留原有 ZIP overlay 路径并继续使用 VLX 1.0.11。
修复应用 module-info.class 的兼容性扫描。模块描述符不含方法体，现在会自动排除在加密范围之外，同时仍可由描述符工具正常读取。
GUI 导出的 CLI 命令现在可以把 --java-version、--target-platform 和 --create-new-folder 作为连续后缀放在打包器参数之后；原有的前缀写法继续兼容。

6.0.9 2026-07-25

加密应用打印空指针异常时的崩溃修复

修复了一个 JVM 崩溃问题：当受保护方法抛出隐式 NullPointerException、且应用读取其消息或打印堆栈时可能触发。运行时的「友好 NPE 提示」功能会尝试从该方法的加密字节码中还原 "because ... is null" 说明文本，进而解引用非法内存、导致 VM 崩溃（在 JavaFX FXML 应用中观察到）。受保护方法现在会跳过该说明文本，退回为标准的 NullPointerException；异常类型、堆栈以及应用自行提供的消息均不受影响。
JDK 17、21 和 25 的运行时随本次修复重建为 VLX 1.0.16。JDK 11 不受影响，因为「友好 NPE 提示」功能在 JDK 14 之前并不存在，继续保持 VLX 1.0.15；JDK 8 继续保持 VLX 1.0.11。

6.0.8 2026-07-24

按需下载的 Tomcat 运行时与生产安全默认值

修复已发布的自保护编码器无法打包 Tomcat WAR 的问题：app.p4jx 中的 Tomcat 类不再以物理 classpath JAR 的形式可见。Tomcat 9.0.107 和 10.1.53 现在作为不可变、带版本号的 R2/COS 制品，按 Servlet 命名空间自动选择，首次使用时下载并缓存在本地，同时核对精确 SHA-256 和 JAR 清单。被篡改的缓存会被丢弃并重新下载。
公开的 WEB-INF/lib JAR 现在会作为按应用隔离、受 Hash 绑定的物理 Web 资源落盘，避免 Spring 启动期间为每个类重复读取和校验嵌套归档。
新构建现在默认使用生产许可端点 https://protector4j.com。只有显式设置 P4JX_LICENSE_MODE=dev 或 -PlicenseMode=dev 时，才会使用内部端点 http://10.10.10.16:16002。

6.0.7 2026-07-24

Tomcat 嵌套依赖与可信动态类

修复受保护的 Tomcat WAR 从 WEB-INF/lib/*.jar 加载类或服务时的失败。Protector4J 现在会将嵌套 JAR 和类的精确 SHA-256 元数据密封到 app.p4jx 中；未知、被替换或被篡改的依赖仍会被拒绝。
修复 JDK 11 的 MethodHandles.Lookup#defineClass 使用 JDK 11 特有来源标记而导致的 Spring CGLIB 和 Hibernate Byte Buddy 失败。动态信任仍必须来自 VM 已验证的调用类或加载器来源；标记字符串、类名、路径、包名和 CodeSource 均不能授予信任。
为 JDK 11、17、21 和 25 发布 VLX 1.0.15 运行时，覆盖 24 个受支持平台组合。全部通过严格的 L1-L5 门禁，包括真实 FXML、Swing/AWT、Tomcat 嵌套依赖加载，以及来源和篡改负向场景。JDK 8 继续保持 VLX 1.0.11。

6.0.6 2026-07-22

可信类定义来源传播

修复受保护 JavaFX FXML 应用启动失败的问题：MethodUtil 会通过 defineClass(byte[]) 定义已由 VM 验证来源的 Trampoline 辅助类。现在信任只从 VM 已验证的类或加载器来源传播，不再来自类名、路径、包名或 CodeSource 字符串。
新增真实 FXML 覆盖，包括 fx:controller、属性元素、Controller 注入和 WebView 启动，并增加可信动态定义、两级传播、未知来源、未授权 JAR 以及替换 protected class 名称的回归测试。
发布 JDK 11、17、21 和 25 的 VLX 1.0.14 运行时。JDK 8 继续保持 VLX 1.0.11。

6.0.5 2026-07-21

JavaFX 原生运行时完整性

通过将打包后的 JavaFX DLL 文件置于 vlxjre/bin，并调整启动器的原生库搜索路径，解决了 Windows 环境下 JavaFX WebView 启动失败的问题（Graphics Device initialization failed / No toolkit found）。
将加密的 app.p4jx 允许列表扩展到外部原生库。无论路径如何，JavaFX 原生文件都必须与精确的 SHA-256 值匹配，同时 Glass 会重新验证实际加载的文件；无法识别或被篡改的文件将被拒绝。
为 JDK 11、17、21 和 25 发布了更新后的 Protector4J 运行时。所支持的 JavaFX 平台组合已通过 L5.1-L5.4，覆盖 WebView 启动，以及对模块 JAR、jdk.jsobject 和 Glass 原生库的篡改拒绝。

6.0.4 2026-07-21

外部模块完整性及 JavaFX 运行时兼容性

已取消对外部模块基于路径的信任机制。现在，每个外部模块 JAR 都必须与嵌入 app.p4jx 的精确 SHA-256 允许列表条目匹配；无论位于何处，未识别或被篡改的文件都会被拒绝。
增加了从 JavaFX module-info.class 自动检测依赖闭包的功能，并严格控制指定 JavaFX 和 JDK 模块的准入，包括 javafx.media 和 jdk.jsobject。
通过新发布的 P4JX 运行时，修复了所有受支持 JDK 版本及平台上的 JavaFX WebView 启动问题，以及启动层建立后的 E818 / ClassFormatError 错误。

6.0.3 2026-07-20

JavaFX WebView 模块兼容性

修复由相同 JDK/VLX 版本重新构建的受支持 P4JX 运行时的可选 jdk.jsobject 解析问题。打包不再仅因完整 lib/modules 镜像字节不同而拒绝兼容运行时。
保留按训练线和平台选择制品、模块精确 SHA-256 与模块名校验，并在安装后重新验证依赖闭包。

6.0.2 2026-07-20

JavaFX WebView 兼容性

修复 JavaFX WebView 启动失败：将 javafx.media 与 javafx.web 一起打包，并在裁剪运行时未包含模块时自动解析与 P4JX 精确匹配的 jdk.jsobject。
新增从区域公共下载服务获取可选模块的功能；制品固定 SHA-256 并绑定版本、平台和运行时。已经包含该模块的运行时会跳过下载。