★ FEATURED ARTICLE 1. 为什么还要折腾 exe4j 这种“老古董”1.1 一个真实的需求场景前阵子帮一个做工业设备上位机的小团队处理交付问题。他们的核心程序是用 Java 写的打包成了一个可执行 jar平时在开发机上双击就能跑命令行java -jar xxx.jar也没问题。但到了客户现场就尴尬了客户的工控机是 Windows 系统装的是某国产安全软件IT 策略卡得很死不允许随意装 JDK更不允许改环境变量。现场操作人员也不是技术人员你让他打开命令行敲java -jar他只会一脸茫然地看着你。这时候最省事的方案就是把 jar 包再包一层做成一个.exe文件。双击就能启动看起来跟普通 Windows 软件没区别还能自定义图标、设置启动参数、绑定一个精简版 JRE 一起发过去。exe4j 就是干这个的它不是什么新技术甚至可以说有点“老”但在“把 Java 程序伪装成原生 Windows 应用”这件事上它依然是很多中小团队交付时的首选工具。这篇文章不打算写成 exe4j 的官方说明书那种东西网上一搜一大把。我想做的是把整个打包流程拆开讲清楚每一步背后的逻辑哪些参数必须调、哪些坑我亲自踩过、遇到问题怎么排查。如果你手里正好有一个需要交付给 Windows 用户的 Java 程序或者你单纯想搞清楚“jar 变 exe”到底发生了什么那这篇内容应该能帮你省下不少试错时间。1.2 exe4j 到底做了什么很多人以为 exe4j 是把 jar 编译成了机器码其实不是。它做的事情更像是一个“启动器生成器”它生成一个原生的 Windows 可执行文件exe这个 exe 内部会去调用 JVM把指定的 jar 加载起来运行。换句话说你的 Java 代码还是跑在 JVM 上exe4j 只是帮你把“找到 JVM、设置 classpath、传参数、启动主类”这一套动作封装成了一个双击就能执行的程序。理解这一点非常关键因为它决定了后面很多配置的意义。比如为什么需要指定 JRE 路径、为什么可以配置 JVM 参数、为什么打包后体积会变大——都是因为 exe 本身只是个壳真正的运行环境还是 JVM。exe4j 的工作流程大致分三步第一步你告诉它你的 jar 在哪、主类是谁第二步你配置 JVM 相关参数和运行环境第三步它生成 exe 和配套的运行时文件。最终交付给用户的通常是一个文件夹里面有 exe、有 jar、可能还有一个精简的 JRE 目录。用户双击 exeexe 找到 JRE启动 JVM加载 jar程序就跑起来了。1.3 它适合谁不适合谁exe4j 最适合的场景是Java 桌面程序、内部工具、工业上位机、教学演示软件交付对象是 Windows 用户且你希望对方“零配置”运行。它支持把 JRE 一起打包这样目标机器完全不需要预装 Java这对交付来说非常友好。但它也有明显的局限。首先它只针对 Windows跨平台需求它满足不了。其次它生成的是启动器不是真正的原生编译所以启动速度会比纯 C 程序慢一些内存占用也还是 JVM 那一套。再者exe4j 是商业软件虽然有个免费版本但免费版会在启动时弹一个提示框正式交付一般还是需要购买授权。如果你追求完全免费可以考虑一些替代方案但 exe4j 在稳定性和配置灵活度上确实有它的优势这也是它一直没被淘汰的原因。2. 动手之前的准备工作2.1 确认你的 jar 是可执行的不是所有 jar 都能直接拿来打包。所谓“可执行 jar”指的是 jar 包的META-INF/MANIFEST.MF文件里明确写了Main-Class这一项。你可以用压缩软件打开 jar找到这个文件看一眼内容大概长这样Manifest-Version: 1.0 Main-Class: com.example.MainApp Class-Path: lib/commons-lang3-3.12.0.jar lib/gson-2.10.jar如果Main-Class缺失双击 jar 是不会运行的exe4j 打包出来的 exe 也会报“找不到主类”。这种情况你需要重新打包或者在 exe4j 配置时手动指定主类。我个人的习惯是在 Maven 或 Gradle 里配置好打包插件确保生成的 jar 自带Main-Class这样后面省事。另外要注意Class-Path这一项。如果你的程序依赖了第三方库而这些库没有被打进同一个 jar也就是所谓的“瘦 jar”那Class-Path里必须列清楚相对路径。exe4j 打包时如果没处理好这些依赖运行时会直接抛ClassNotFoundException。我一般推荐打成“胖 jar”把所有依赖都塞进一个 jar 里虽然体积大一点但依赖关系简单不容易出错。2.2 准备一个可用的 JREexe4j 本身不包含 JRE它需要你提供一个。这里有个关键选择是用完整 JDK 还是精简 JRE答案很明确用 JRE而且最好是针对目标系统精简过的。JDK 里那些编译器、调试工具对最终用户毫无意义只会让交付包体积暴涨。如果你用的是 Java 8可以拿jre目录直接用。如果是 Java 9 以上情况稍微复杂一点因为模块化之后没有独立的 JRE 目录了你需要用jlink自己生成一个。比如jlink --module-path %JAVA_HOME%\jmods --add-modules java.base,java.desktop,java.logging --output myjre --strip-debug --compress2这条命令会生成一个只包含基础模块、桌面模块和日志模块的精简 JRE体积可能只有完整 JDK 的三分之一甚至更少。--strip-debug去掉调试信息--compress2压缩都是为了减小体积。具体加哪些模块取决于你的程序用了哪些功能比如用了 Swing 就得加java.desktop用了 XML 解析就得加java.xml。加少了运行时报NoClassDefFoundError加多了体积大这个平衡需要根据实际项目调。2.3 确认目标系统的位数这个坑我踩过。有一次打包好的 exe 在开发机上跑得好好的到了客户那边直接提示“不是有效的 Win32 应用程序”。原因就是开发机是 64 位打包时用的 JRE 也是 64 位但客户那台老工控机是 32 位系统。exe4j 生成的启动器本身是跟 JRE 位数绑定的32 位 JRE 配 32 位启动器64 位配 64 位不能混。所以打包前一定要确认目标机器的系统架构。如果不确定最稳妥的办法是准备两套一套 32 位一套 64 位分别打包。或者干脆在项目说明里写清楚系统要求。现在纯 32 位的 Windows 已经很少了但工业现场的老设备什么情况都有多留个心眼没坏处。3. exe4j 配置全流程拆解3.1 新建配置与项目类型选择打开 exe4j第一件事是选择项目类型。它提供了几种模式最常用的是“Regular mode”也就是标准模式适合大多数场景。另外还有“Service mode”用于把程序注册成 Windows 服务这个一般用不到。如果你只是做一个双击启动的桌面程序选 Regular mode 就行。接下来是配置项目名称和输出路径。这里建议输出路径单独建一个空文件夹因为 exe4j 生成的文件不止一个 exe还会有一些中间文件和运行时目录混在项目目录里会很乱。我习惯在项目根目录下建一个dist文件夹专门放打包产物每次打包前清空保证干净。3.2 配置主 jar 与主类这一步是核心。在“Executable info”或者“Application info”页面你需要添加你的 jar 文件。exe4j 支持添加多个 jar顺序很重要主 jar 放最前面依赖 jar 放后面。如果你用的是胖 jar那就只加一个。添加完 jar 后exe4j 通常会自动扫描Main-Class。如果没扫到你就得手动填。手动填的时候要写全限定类名比如com.example.MainApp不要写成MainApp或者带.class后缀。这个细节看起来简单但新手经常在这里卡住。还有一个选项叫“Main class from manifest”意思是让 exe4j 从 jar 的 MANIFEST 里读主类。如果你的 jar 是标准可执行 jar勾上这个最省事。但如果你的 MANIFEST 写得不规范或者你想临时换一个主类启动那就取消勾选手动指定。3.3 JVM 参数与运行环境配置这一块是 exe4j 真正体现灵活性的地方。你可以配置 JVM 的初始堆大小、最大堆大小、系统属性、临时目录等。比如-Xms256m初始堆 256MB-Xmx1024m最大堆 1GB-Dfile.encodingUTF-8强制文件编码避免中文乱码-Djava.awt.headlessfalse如果程序有界面确保不是无头模式这些参数会写进 exe 的启动配置里用户双击时自动生效不需要他手动设置。对于桌面程序来说-Xmx别设太大否则在内存小的机器上启动会失败也别设太小否则程序跑着跑着就OutOfMemoryError。我的经验是先看程序实际峰值内存占用然后在此基础上留 50% 余量。还有一个重要选项是“JRE path”。你可以指定一个相对路径比如jre然后把精简 JRE 放在 exe 同级目录下。这样整个文件夹拷到任何 Windows 机器上都能跑不需要目标机器装 Java。如果你指定的是绝对路径那换台机器就可能找不到所以强烈建议用相对路径。3.4 打包 JRE 与生成 exe在“JRE”配置页面exe4j 提供了“Bundle JRE”的选项。勾上之后它会把指定的 JRE 目录一起复制到输出目录。注意它只是复制不会压缩所以最终文件夹体积就是 JRE 加 jar 加 exe 的总和。一个精简 JRE 大概 40 到 80MB胖 jar 看项目大小最终交付包一两百 MB 很正常。生成 exe 的时候exe4j 会问你要不要设置图标。这个图标必须是.ico格式不能直接拿.png或.jpg改后缀。网上有很多在线转换工具或者用 ImageMagick 转magick convert logo.png -define icon:auto-resize256,128,64,48,32,16 logo.ico这条命令会生成一个包含多种尺寸的 ico 文件Windows 在不同视图下会自动选择合适的尺寸显示效果更好。如果只放一个尺寸在某些视图下会模糊。生成完成后你会得到一个 exe 文件和一个jre目录如果勾了打包 JRE。双击 exe 测试如果程序正常启动说明配置基本没问题。4. 那些年我踩过的坑与排查方法4.1 启动报错“找不到主类”怎么办这是最常见的问题没有之一。报错信息通常是Could not find the main class或者NoClassDefFoundError。排查思路分三步走。第一步确认 jar 本身能不能跑。在命令行执行java -jar your.jar如果这一步就报错那问题在 jar 本身跟 exe4j 无关。检查 MANIFEST 里的Main-Class拼写是否正确类名大小写是否匹配。第二步确认 exe4j 里配置的主类跟 jar 里的一致。有时候 jar 更新了主类改了名但 exe4j 配置没同步就会出问题。重新扫描一下或者手动改过来。第三步检查依赖 jar 是否齐全。如果程序依赖了第三方库而这些库没有打进主 jar也没有在 exe4j 里添加运行时就会找不到类。解决办法要么打成胖 jar要么在 exe4j 的 classpath 里把所有依赖 jar 都加进去。4.2 中文乱码与编码问题Java 程序在 Windows 上中文乱码是个老生常谈的问题。exe4j 打包后如果没指定编码JVM 会默认用系统编码而中文 Windows 默认是 GBK。如果你的程序内部用 UTF-8 处理字符串读写文件或者控制台输出时就可能乱码。解决办法是在 JVM 参数里加-Dfile.encodingUTF-8。但要注意这个参数在 Java 18 之后行为有变化官方推荐用-Dstdout.encoding和-Dstderr.encoding分别控制。如果你用的是 Java 8 到 Java 17-Dfile.encodingUTF-8基本够用。另外程序里读写文件时最好显式指定编码不要依赖默认值这样最稳妥。还有一个隐藏的坑exe4j 生成的 exe 在启动时如果路径里有中文或空格也可能导致 JRE 找不到。所以输出目录和 JRE 路径尽量用纯英文不要有空格。我一般用D:\build\output这种简单路径避免不必要的麻烦。4.3 内存不足与启动闪退程序双击后闪一下就没了没有任何提示这种情况通常是启动阶段就崩了。可能的原因有几个JRE 路径不对、JVM 参数有误、内存设置过大导致 JVM 无法初始化。排查方法是把 exe 拖到命令行里执行这样能看到控制台输出。比如D:\dist\myapp.exe如果 JVM 初始化失败会打印具体错误。常见的是Error occurred during initialization of VM后面跟着Could not reserve enough space for object heap这说明-Xmx设得太大了超过了系统可用内存或地址空间。把-Xmx调小一点再试。另一个原因是 JRE 位数跟系统不匹配。32 位 JRE 在 64 位系统上能跑但最大堆只能到 1.5G 左右64 位 JRE 在 32 位系统上直接跑不起来。确认一下目标系统位数选对应的 JRE。4.4 杀毒软件误报与签名问题这个坑很恶心。exe4j 生成的 exe 有时候会被某些安全软件误报为风险程序尤其是没有数字签名的 exe。客户那边一打开就弹警告体验很差。解决办法有几个一是给 exe 加数字签名这需要购买代码签名证书成本较高但最正规二是把 exe 提交给安全厂商做白名单流程比较慢三是在交付说明里写清楚让客户手动添加信任。如果只是内部使用第三个办法最省事。如果是商业交付建议还是走签名路线否则每次都被拦截很影响专业形象。另外exe4j 免费版生成的 exe 启动时会弹一个“This executable was created with an evaluation version of exe4j”的提示框这个在正式交付时肯定不能接受。所以如果项目要对外发布还是得购买授权或者考虑其他方案。5. 进阶技巧与替代方案对比5.1 减小交付包体积的几种手段交付包太大拷贝和分发都麻烦。除了前面说的用jlink精简 JRE还有几个办法可以试试。第一用 ProGuard 或 R8 对 jar 做混淆和压缩去掉没用的类和方法。这个对体积的缩减效果很明显有时候能减少一半以上。但要注意混淆可能会影响反射、序列化等功能需要配置好保留规则。第二检查 JRE 里有没有多余的文件。比如jre\lib\ext目录下的东西、jre\bin里的一些调试工具都可以删掉。但删之前要确认程序不依赖它们否则运行时会报错。第三如果程序没有界面可以考虑用--compress2进一步压缩 JRE。不过这个压缩是 jlink 层面的对已经生成的 JRE 目录直接压缩效果有限。我一般会把最终交付包控制在 100MB 以内超过这个数就要审视一下是不是有可以裁剪的东西。当然如果程序本身依赖了很多大型库那体积大也是没办法的事。5.2 exe4j 与其他打包工具的取舍市面上能把 Java 程序打包成 exe 的工具不止 exe4j 一个。比如 Launch4j它是开源的免费配置也比较简单但功能没有 exe4j 那么丰富尤其是打包 JRE 这块支持得不够好。还有 GraalVM Native Image它能把 Java 程序直接编译成原生可执行文件启动快、体积小但兼容性有限很多反射、动态代理的代码跑不了适合新项目不适合老项目。我个人的选择逻辑是如果项目是传统的 Java 桌面程序依赖复杂需要打包 JRE那就用 exe4j如果只是简单包装一下目标机器已经装了 Java那 Launch4j 够用如果是新项目且追求极致启动速度可以试试 GraalVM但要做好踩坑的准备。exe4j 的优势在于稳定和灵活它在这个领域活了这么多年各种边界情况都有人踩过社区里能找到的解决方案也多。对于交付型项目来说稳定比时髦重要。5.3 自动化打包的思路如果每次发版都要手动打开 exe4j 点一遍效率太低还容易出错。exe4j 其实支持命令行调用你可以把配置文件保存成.exe4j文件然后用命令行执行打包exe4j.exe -c myconfig.exe4j -d output这样就能集成到 CI/CD 流程里每次构建自动生成 exe。配置文件里可以定义变量比如版本号、输出路径通过命令行参数传入实现不同环境的差异化打包。我一般会在项目里放一个build-exe.bat脚本内容大概是先调 Maven 打包 jar再调 exe4j 生成 exe最后把 JRE 和 exe 拷到发布目录。整个流程一键完成减少人为失误。脚本里记得加错误检查比如 jar 打包失败就退出不要继续往下走。6. 一些零散但重要的经验打包完成后一定要在干净的测试环境里验证。什么叫干净就是一台没装过 JDK、没配过 Java 环境变量的 Windows 机器。虚拟机也行但最好是全新安装的系统。我见过太多次在开发机上跑得好好的到客户那边就各种问题根源就是开发机上的环境变量、注册表残留影响了测试结果。测试的时候重点看几个地方程序能不能启动、界面显示是否正常、文件读写有没有权限问题、退出时有没有残留进程。尤其是权限问题Windows 的 UAC 有时候会拦截程序对某些目录的写入如果你的程序需要写配置文件到安装目录最好改成写到用户目录下比如%APPDATA%。还有一点exe4j 生成的 exe 默认工作目录是 exe 所在目录。如果你的程序用相对路径读取资源文件要确保这些文件跟 exe 的相对位置正确。我一般会把资源文件放在 exe 同级的resources目录下程序里用System.getProperty(user.dir)获取当前目录再拼接路径。但要注意如果用户从快捷方式启动工作目录可能会变所以更稳妥的做法是用 exe 的绝对路径来定位资源。最后说一个关于版本管理的小技巧。每次打包生成的 exe 和 JRE 目录建议按版本号命名文件夹比如myapp-1.0.0-win64里面再放 exe 和 jre。这样多个版本共存时不会混淆回滚也方便。交付给客户时直接给这个文件夹让他解压到任意位置就能用不需要安装也不需要管理员权限这才是绿色软件该有的样子。
阅读完成 · 觉得有帮助？
