JEP draft: Deprecate the Pack200 tools and API

OwnerKumar Srinivasan
Created2018/04/04 17:11
Updated2018/05/17 23:37
Discussionjdk dash dev at openjdk dot java dot net
Reviewed byAlex Buckley, John Rose
Endorsed byJohn Rose


Deprecate the pack200 and unpack200 tools, and the Pack200 API in java.util.jar.


Pack200 is a compression scheme for JAR files. It was introduced in Java SE 5.0 by JSR-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 and uncompress their JAR files. An API is available in the java.util.jar package.

There are three reasons for wanting to deprecate (and eventually 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) and the modules used to build the runtime (JMOD). 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. The Java deployment stack supports the distribution of client applications compressed with Pack200. Specifically, the Java Plug-In (for applets) and Java Web Start (for JNLP applications) can uncompress application JARs automatically. However, according to Oracle's Java Client Roadmap Update, the Java Plug-In and Java Web Start are not included in JDK 11 or later. In effect, an entire class of consumers of Pack200 -- client applications running on the deployment stack -- are no longer a driver for including Pack200 in the JDK.

  3. Pack200 is a complex and elaborate technology. The file format is tightly coupled to the class file format and the JAR file format, both of which have evolved in ways unforeseen by JSR-200. (For example, JEP 309 added a new kind of constant pool entry to the class file format, and JEP 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 modularization of the Java SE Platform, leading to the removal of four of its methods in Java SE 9. 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 will be terminally deprecated, that is, annotated with @Deprecated(forRemoval=true):

The jdk.pack module which contains the pack200 and unpack200 tools will also be terminally deprecated.

Running pack200 or unpack200 will display a warning about planned removal of the tool. Running jar -c with the sub-option n (to normalize the archive) will display a warning about planned removal of the sub-option. The documentation for all three tools will indicate the deprecation and planned removal.

A separate JEP will be filed for the actual removal of the types and module in a future JDK feature release.

Risks and Assumptions

Per Oracle's Java Client Roadmap Update, it is assumed that developers who use pack200 to shrink application JARs will switch to the jlink tool to create application-specific runtimes with an optimized form factor. See the tool documentation and JEP 282.