JEP 367：删除 Pack200 工具和 API
概括
删除包中的pack200和unpack200工具以及API 。这些工具和 API 已在 Java SE 11 中弃用并删除，并明确打算在未来版本中删除它们。Pack200``java.util.jar
动机
Pack200是 JAR 文件的压缩方案，由JSR 200在 Java SE 5.0 中引入。其目标是“降低 Java 应用程序打包、传输和交付的磁盘和带宽要求”。开发人员使用一对工具pack200来unpack200压缩和解压缩他们的 JAR 文件。包中提供了API。java.util.jar
删除 Pack200 的原因有以下三个：
-
从历史上看，通过 56k 调制解调器下载 JDK 的速度缓慢是 Java 采用的障碍。 JDK 功能的不断增长导致下载大小膨胀，进一步阻碍了采用。使用 Pack200 压缩 JDK 是缓解该问题的一种方法。然而，时间在进步：下载速度有所提高，并且 JDK 9 为 Java 运行时 ( JEP 220 ) 和用于构建运行时的模块 ( JMOD ) 引入了新的压缩方案。因此，JDK 9 及更高版本不依赖 Pack200； JDK 8 是最后一个在
pack200构建时压缩并unpack200在安装时解压缩的版本。总之，Pack200 的主要消费者——JDK 本身——不再需要它。 -
除了 JDK 之外，使用 Pack200 压缩客户端应用程序（尤其是小程序）也很有吸引力。某些部署技术（例如 Oracle 的浏览器插件）会自动解压缩 applet JAR。然而，客户端应用程序的情况已经发生了变化，大多 数浏览器已经放弃了对插件的支持。因此，Pack200 的一类主要消费者（在浏览器中运行的小程序）不再是在 JDK 中包含 Pack200 的驱动程序。
-
Pack200 是一项复杂而精细的技术。它的文件格式与类文件格式和JAR 文件格式紧密耦合，这两种格式都以 JSR 200 无法预见的方式发展。（例如，JEP 309在类文件格式中添加了一种新的常量池条目，并且JEP 238在 JAR 文件格式中添加了版本控制元数据。）JDK 中的实现分为 Java 和本机代码，这使得维护变得困难。中的 API
java.util.jar.Pack200不利于 Java SE 平台的模块化，导致Java SE 9 中删除了其四个方法。总的来说，维护 Pack200 的成本是巨大的，并且超过了将其包含在 Java SE 和 JDK 中的好处。
描述
java.base先前注释的模块中的三种类型将在该 JEP 最终目标的 JDK 功能版本中@Deprecated(forRemoval=true) 删除：
java.util.jar.Pack200java.util.jar.Pack200.Packerjava.util.jar.Pack200.Unpacker
该jdk.pack模块包含pack200和unpack200工具，之前已注释过，@Deprecated(forRemoval=true)并且也将在该 JEP 最终目标的 JDK 功能版本中删除。
风险和假设
我们假设依赖 Pack200 的开发人员已经充分注意到其拟议的删除，以便做出替代安排。 JDK 11 中弃用并删除 Pack200 的提议于 2018 年 6 月提出并得到确认，从那时起，人们就不再对该主题感兴趣了。 （Eclipse 社区是 Pack200 的重要用户，也进行了自己的讨论 ( 1 , 2 )，但没有报告进一步的进展。） Java SE 11Pack200的 Platform JSR 中标记了该 API 的弃用删除，并且随后适用于Java SE 12和Java SE 13。 Platform JSR 的邮件列表 ( 1 , 2 )上没有收到关于拟议删除的评论。
我们假设使用pack200缩小应用程序 JAR 的开发人员可以切换到该jlink工具，或者使用该jpackage工具来创建具有优化外形的特定于应用程序的运行时。有关这些工具的更多信息，请参阅JEP 282和JEP 343 。 JDK 14 的早期访问版本jpackage已可用。