JEP 367: 移除 Pack200 工具和 API
概述
移除 pack200 和 unpack200 工具，以及 java.util.jar 包中的 Pack200 API。这些工具和 API 在 Java SE 11 中已被标记为弃用并计划移除，明确表示将在未来的版本中删除。
动机
移除 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 的浏览器插件）会自动解压缩小程序的 JAR 文件。然而，客户端应用程序的格局已经发生了变化，大多数浏览器已停止支持插件。因此，Pack200 的一大类使用者——在浏览器中运行的小程序——不再是将 Pack200 包含在 JDK 中的驱动因素。
-
Pack200 是一种复杂且精细的技术。它的文件格式与class 文件格式和JAR 文件格式紧密耦合，而这两种格式都以 JSR 200 无法预见的方式发展。（例如，JEP 309 在 class 文件格式中添加了一种新的常量池条目，而 JEP 238 在 JAR 文件格式中添加了版本控制元数据。）JDK 中的实现分散在 Java 和原生代码之间，这使得维护变得困难。
java.util.jar.Pack200中的 API 对 Java SE 平台的模块化产生了不利影响，导致Java SE 9 中移除了其四个方法。总体而言，维护 Pack200 的成本很高，超过了将其包含在 Java SE 和 JDK 中所带来的好处。
描述
java.base 模块中之前标注了 @Deprecated(forRemoval=true) 的三种类型 将会被移除，这一 JEP 最终目标的 JDK 特性发布版本中：
java.util.jar.Pack200java.util.jar.Pack200.Packerjava.util.jar.Pack200.Unpacker
jdk.pack 模块包含 pack200 和 unpack200 工具，之前已被标注为 @Deprecated(forRemoval=true)，并且在最终包含此 JEP 的 JDK 特性发布版本中 也将被移除。
风险与假设
我们假设依赖 Pack200 的开发者已经收到了关于其计划移除的足够通知，以便做出替代安排。Pack200 在 JDK 11 中的“为移除而弃用”提议于 2018 年 6 月被提出并确认，此后再无更多关于该主题的兴趣。（Eclipse 社区是 Pack200 的一个重要使用者，曾进行过自己的讨论（1，2），但未报告进一步进展。）Pack200 API 的“为移除而弃用”在 Java SE 11 的平台 JSR 中被标记，并随后在 Java SE 12 和 Java SE 13 中再次标记。平台 JSR 的邮件列表（1，2）未收到任何关于提议移除的评论。