【记一次jpackage 打包无限递归套娃、GCD 文件夹嵌套占满内存的JDK21~23 已知 Bug 的完整解决方案】

前言近期使用 JDK 自带jpackage工具打包 Java 程序为 Windows exe 可执行文件本以为是官方原生打包工具稳定性拉满结果踩了严重深坑打包流程触发无限递归持续生成多层嵌套文件夹直至磁盘占满、内存溢出。如果你打包时遇到GCD/app/GCD/app/...这类文件夹无限套娃问题本文将完整说明问题根源、复现流程与可直接落地的解决办法该问题并非操作失误而是 JDK 官方已知 Bug。一、问题复现文件夹无限嵌套死循环业务需求源码输入目录C:\Users...\Desktop\build目录内仅存在Test.jar预期输出在 build 目录下生成 GCD 文件夹内部存放打包产物GCD.exe执行打包命令jpackage--typeapp-image--inputC:\Users\...\Desktop\build --main-jar Test.jar--nameGCD--tempC:\temp--destC:\Users\...\Desktop\build异常现象命令运行后虽然生成了预期 exe 文件但build目录疯狂递归创建GCD嵌套文件夹一层套一层。若不手动CtrlC终止进程会持续占用磁盘空间、消耗内存行为类似病毒文件扩散。二、排查踩坑指定 --temp 临时目录依旧失效网上绝大多数教程提到配置--temp独立临时目录即可规避路径冲突按照教程操作后问题并未解决排查关键点如下单独创建空临时目录C:\temp输入目录 build 仅保留纯净Test.jar无多余文件核心错误--input输入目录与--dest输出目录指定了同一个文件夹C:\Users...\Desktop\build。即便隔离临时目录输入输出同源目录依旧会触发无限递归。三、问题根本原因JDK 官方已知 Bug JDK-8325089经官方资料核对该异常为jpackage工具原生逻辑缺陷并非使用者操作错误Bug 编号JDK-8325089受影响版本JDK 21、JDK 22、JDK 23触发条件--input输入目录 和--dest输出目录为同一路径底层逻辑打包时工具会持续扫描输入目录输出目录与输入目录重合后正在生成的打包产物会被二次识别为源码输入循环重复打包逻辑最终无限生成嵌套文件夹。简单概括低版本 JDK 的 jpackage 不支持原地打包缺少目录隔离逻辑。四、终极可行解决方案核心解决思路物理隔离输入、临时、输出三类目录严禁输入与输出共用同一文件夹。下面的例子以D:盘为例和上文的C:盘并无区别这里只是为了方便大家直接测试。1. 目录规划规范目录类型示例路径用途说明--input 输入目录D:\jpackage\input仅存放待打包 Jar 包不放置其他文件--temp 临时目录D:\jpackage\temp打包缓存目录打包完成后可直接删除--dest 输出目录D:\jpackage\output最终 exe 程序产物存放位置2. Windows 标准打包命令换行符 ^jpackage--typeapp-image ^--inputD:\jpackage\input ^ --main-jar Test.jar ^--nameGCD ^--tempD:\jpackage\temp ^--destD:\jpackage\output注Windows 命令行换行符是 ^Linux/Mac 是 \如果在一行写则去掉换行符)3. 验证结果执行完成后进入D:\jpackage\output\GCD路径可正常生成GCD.exe无多余嵌套文件夹打包流程正常结束。五、避坑指南与替代打包方案方案 1升级 JDK 版本根治 Bug该 Bug 已在 JDK 24 版本修复若使用 JDK24 及以上版本无需区分输入输出目录支持原地打包。方案 2第三方工具 Launch4j老牌 Jar 转 Exe 工具规避 jpackage 递归问题优点可视化配置简单生成 exe 体积小巧无文件夹套娃 Bug缺点仅做 Jar 包外层封装目标运行设备需要单独安装 JRE可手动捆绑 JRE 解决。六、嵌套文件夹清理技巧若已经生成多层超长嵌套文件夹系统直接删除会提示「文件路径过长无法访问」解决办法使用 WinRAR、7-Zip 压缩软件打开该根目录选中顶层文件夹按下Shift Delete强制彻底删除。总结JDK21~23 版本内置 jpackage 工具存在JDK-8325089路径递归 Bug使用时必须保证--input输入目录与--dest输出目录为两个独立物理文件夹。本文完整复现问题、定位根源并提供可直接复制的打包命令能节省大量调试排查时间。