JarOutputStream构建可执行变量JAR包的规范

用JarOutputStream构建可执行JAR包，很多人第一反应是“不就是打个压缩包吗”。但真正动手做起来才发现，关键其实不在“压缩”，而在严格遵循JAR规范——尤其是条目顺序、路径格式、时间戳和清单文件（META-INF/MANIFEST.MF）的写入时机与内容。稍有偏差，就可能造成无法启动、解压失败或类加载异常。先说说几个容易踩坑的地方。

MANIFEST.MF必须是第一个条目，且含Main-Class

Ja va运行时有个硬性要求：META-INF/MANIFEST.MF必须作为归档中的首个条目。否则，某些环境（比如旧版ClassLoader或Ja va Web Start）会直接忽略它。那么，怎么让它支持ja va -jar启动？必须在manifest主属性中明确设置Main-Class。操作顺序也很关键：先创建Manifest实例，调用manifest.getMainAttributes().put(Attributes.Name.MAIN_CLASS, "com.example.Main")；再构造JarEntry("META-INF/MANIFEST.MF")；紧接着调用jarOut.putNextEntry(entry)；然后用manifest.write(jarOut)写入内容；最后，千万别忘了jarOut.closeEntry()。这一步的次序错了，整个包可能就无法正确识别。

所有JarEntry路径必须规范

JAR内部的路径不是文件系统路径，而是ZIP标准路径，规则是固定的。一律使用正斜杠/作分隔符，反斜杠\是禁区。路径不能以/开头，比如/com/example/MyClass.class就是错的。类文件路径应为相对形式，像"com/example/MyClass.class"才是正确的。目录条目（比如空包）可以显式添加，结尾加/，例如"com/example/"，但这并非强制要求——JAR工具能自动推导。不过，保持规范总没坏处。

每个条目必须显式设置时间戳并配对closeEntry

这一点最容易忽略。JarEntry默认的时间戳在部分JDK版本中为1980-01-01 00:00:00，这会导致解压工具报错或校验失败。因此，务必调用entry.setTime(System.currentTimeMillis())，或者统一设置成一个确定值（比如构建时统一用1717027200000L对应2024-05-30）。每次putNextEntry()后，必须立即调用closeEntry()，否则后续写入的数据可能被截断。推荐全程使用try-with-resources管理JarOutputStream，这样可以避免手动flush()或close()遗漏。

资源写入需注意流管理与字节处理

向JAR中写入class、配置或其他二进制资源时，要确保数据完整、不混杂。每个资源对应一个独立的JarEntry，不可复用entry对象。用BufferedInputStream读取源文件，配合固定大小的缓冲区（如byte[8192]），循环read() + write()。不要依赖a vailable()判断长度——以read()返回值是否为-1为准。另外，如果想把外部JAR包嵌入（非依赖路径），应作为普通资源写入，路径按需指定（如"lib/xxx.jar"）。但需要注意的是，标准的ja va -jar不会自动加载子JAR，需要自定义类加载器，或者改用Spring Boot、Ma ven Shade等更成熟的方案。