Remove the `pack200` and `unpack200` tools, and the `Pack200` API in the `java.util.jar` package. These tools and API were [deprecated for removal in Java SE 11](http://openjdk.java.net/jeps/336) with the express intent to remove them in a future release.
[Pack200](https://docs.oracle.com/en/java/javase/13/docs/specs/pack-spec.html) is a compression scheme for JAR files, introduced in Java SE 5.0 by [JSR 200](https://jcp.org/en/jsr/detail?id=200). Its goal is "to decrease disk and bandwidth requirements for Java application packaging, transmission, and delivery." Developers use a pair of tools -- `pack200` and `unpack200` -- to [compress](https://docs.oracle.com/en/java/javase/13/docs/specs/man/pack200.html) and [uncompress](https://docs.oracle.com/en/java/javase/13/docs/specs/man/unpack200.html) their JAR files. [An API](https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/util/jar/Pack200.html) is available in the `java.util.jar` package.
There are three reasons to remove Pack200:
1. Historically, slow downloads of the JDK over 56k modems were an impediment to Java adoption. The relentless growth in JDK functionality caused the download size to swell, further impeding adoption. Compressing the JDK with Pack200 was a way to mitigate the problem. However, time has moved on: download speeds have improved, and JDK 9 introduced new compression schemes for both the Java runtime ([JEP 220](http://openjdk.java.net/jeps/220)) and the modules used to build the runtime ([JMOD](http://openjdk.java.net/jeps/261#Packaging:-JMOD-files)). Consequently, JDK 9 and later do not rely on Pack200; JDK 8 was the last release compressed with `pack200` at build time and uncompressed with `unpack200` at install time. In summary, a major consumer of Pack200 -- the JDK itself -- no longer needs it.
2. Beyond the JDK, it was attractive to compress client applications, and especially applets, with Pack200. Some deployment technologies, such as Oracle's browser plug-in, would uncompress applet JARs automatically. However, the landscape for client applications has changed, and most browsers have dropped support for plug-ins. Consequently, a major class of consumers of Pack200 -- applets running in browsers -- are no longer a driver for including Pack200 in the JDK.
3. Pack200 is a complex and elaborate technology. Its [file format](https://docs.oracle.com/en/java/javase/13/docs/specs/pack-spec.html) is tightly coupled to the [class file format](https://docs.oracle.com/javase/specs/jvms/se13/html/jvms-4.html#jvms-4.1) and the [JAR file format](https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html), both of which have evolved in ways unforeseen by JSR 200. (For example, [JEP 309](http://openjdk.java.net/jeps/309) added a new kind of constant pool entry to the class file format, and [JEP 238](http://openjdk.java.net/jeps/238) added versioning metadata to the JAR file format.) The implementation in the JDK is split between Java and native code, which makes it hard to maintain. The API in `java.util.jar.Pack200` was detrimental to the modularization of the Java SE Platform, leading to [the removal of four of its methods in Java SE 9](http://cr.openjdk.java.net/~iris/se/9/java-se-9-fr-spec/#APIs-removed). Overall, the cost of maintaining Pack200 is significant, and outweighs the benefit of including it in Java SE and the JDK.
Three types in the `java.base` module previously annotated with `@Deprecated(forRemoval=true)` **will be removed** in the JDK feature release to which this JEP is ultimately targeted:
The `jdk.pack` module, which contains the `pack200` and `unpack200` tools, was previously annotated with `@Deprecated(forRemoval=true)` and **will also be removed** in the JDK feature release to which this JEP is ultimately targeted.
Risks and Assumptions
We assume that developers who rely on Pack200 have had enough notice about its proposed removal to make alternative arrangements. The deprecation-for-removal of Pack200 in JDK 11 was [proposed](https://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001340.html) and [confirmed](https://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001358.html) in June 2018, with no further interest in the topic since that time. (The Eclipse community, a significant consumer of Pack200, held discussions of its own ((https://www.eclipse.org/lists/p2-dev/2018/Jun/index.html), (https://www.eclipse.org/lists/p2-dev/2018/Jul/index.html)) but no further progress was reported.) The deprecation-for-removal of the `Pack200` API was flagged in the Platform JSR for [Java SE 11](http://cr.openjdk.java.net/~iris/se/11/latestSpec/#APIs-proposed-for-removal), and subsequently for [Java SE 12](http://cr.openjdk.java.net/~iris/se/12/latestSpec/#APIs-proposed-for-removal) and [Java SE 13](http://cr.openjdk.java.net/~iris/se/13/latestSpec/#APIs-proposed-for-removal). No comments were received on the Platform JSR's mailing lists ((http://mail.openjdk.java.net/mailman/listinfo/java-se-spec-experts), (http://mail.openjdk.java.net/mailman/listinfo/java-se-spec-comments)) about the proposed removal.
We assume that developers who use `pack200` to shrink application JARs can switch to either the `jlink` tool or the `jpackage` tool to create application-specific runtimes with an optimized form factor. See [JEP 282](http://openjdk.java.net/jeps/282) and [JEP 343](http://openjdk.java.net/jeps/343) for more information about these tools. An early-access build of JDK 14 that includes `jpackage` is [available](https://jdk.java.net/jpackage/).