JEP 336: Deprecate the Pack200 Tools and API

Аннотация

Объявить устаревшими инструменты pack200 и unpack200, а также API Pack200 в java.util.jar.

Мотивация

Pack200 — схема сжатия JAR-файлов. Она появилась в Java SE 5.0 благодаря JSR 200. Её цель — «уменьшить требования к дисковому пространству и пропускной способности канала при упаковке, передаче и доставке Java-приложений». Разработчики используют пару инструментов — pack200 и unpack200 — чтобы сжимать и распаковывать свои JAR-файлы. API доступен в пакете java.util.jar.

Есть три причины объявить Pack200 устаревшим (и в конечном итоге удалить):

1. Исторически медленная загрузка JDK через модемы 56k мешала распространению Java. Непрерывный рост функциональности JDK увеличивал размер загрузки, что ещё больше мешало распространению. Сжатие JDK с помощью Pack200 было способом смягчить проблему. Однако времена изменились: скорость загрузки выросла, а в JDK 9 появились новые схемы сжатия как для среды выполнения Java (JEP 220), так и для модулей, из которых собирается среда выполнения (JMOD). Поэтому JDK 9 и более поздние версии не зависят от Pack200; JDK 8 был последним выпуском, который сжимался с помощью pack200 при сборке и распаковывался с помощью unpack200 при установке. Итак, один из основных потребителей Pack200 — сам JDK — больше в нём не нуждается.

2. Помимо JDK, с помощью Pack200 было удобно сжимать клиентские приложения, и особенно апплеты. Некоторые технологии развёртывания, например браузерный плагин Oracle, автоматически распаковывали JAR-файлы апплетов. Однако ситуация с клиентскими приложениями изменилась, и большинство браузеров прекратили поддержку плагинов. Поэтому целый класс основных потребителей Pack200 — апплеты, работающие в браузерах, — больше не является причиной включать Pack200 в JDK.

3. Pack200 — сложная и тщательно проработанная технология. Её формат файлов тесно связан с форматом class-файлов и форматом JAR-файлов, и оба они развивались так, как в JSR 200 не предполагалось. (Например, JEP 309 добавил в формат class-файлов новый вид записи пула констант, а JEP 238 добавил в формат JAR-файлов метаданные версий.) Реализация в JDK разделена между кодом на Java и нативным кодом, из-за чего её трудно сопровождать. API в java.util.jar.Pack200 мешал модуляризации платформы Java SE, что привело к удалению четырёх его методов в Java SE 9. В целом затраты на сопровождение Pack200 значительны и перевешивают пользу от его включения в Java SE и JDK.

Описание

Три типа в модуле java.base получат статус Deprecated for Removal (устаревший, будет удалён), то есть будут помечены аннотацией @Deprecated(forRemoval=true):

• java.util.jar.Pack200
• java.util.jar.Pack200.Packer
• java.util.jar.Pack200.Unpacker

Модуль jdk.pack, содержащий инструменты pack200 и unpack200, также получит статус Deprecated for Removal.

При запуске pack200 или unpack200 будет выводиться предупреждение о запланированном удалении инструмента. При запуске jar -c с подопцией n (для нормализации архива) будет выводиться предупреждение о запланированном удалении подопции. В документации всех трёх инструментов будет указано, что они устарели и их планируется удалить.

Для фактического удаления типов и модуля в одном из будущих выпусков JDK типа Feature Release (функциональный выпуск) будет подан отдельный JEP.

Риски и допущения

Предполагается, что разработчики, которые используют pack200 для уменьшения JAR-файлов приложений, перейдут на инструмент jlink, чтобы создавать среды выполнения под конкретное приложение с оптимизированным размером. См. документацию инструмента и JEP 282. Ещё одним вариантом может стать инструмент jpackage (JEP 343).