JEP 208: Java Packager Improvements

Аннотация

Добавить в Java Application Packager новые возможности и упаковщики (bundlers), а также улучшить работу с нативной платформой.

Цели

Продолжить развитие Java Packager, начатое в 8u20. В выпуске 8u20 существующий JavaFX Packager обновлён так, чтобы он мог создавать пакеты приложений с нативным лаунчером и собственной копией JRE как для приложений Swing, так и для приложений FX, и чтобы инструмент можно было адаптировать для работы со всеми распространёнными IDE. Следующее обновление призвано ещё больше улучшить пользовательский опыт за счёт запрошенных возможностей, дополнительных упаковщиков, улучшенного API и более точного соответствия нативной платформе.

Что не является целью

Внедрение инструмента крупными производителями IDE выходит за рамки этих требований.

Мотивация

Существующая возможность упаковки приложений в FX Packager ограниченно поддерживает магазины приложений и приложения без FX. Кроме того, ей не хватает гибкости, когда её используют в существующем процессе сборки. Эти улучшения к работе, которая уже ведётся для 8u20, упростят интеграцию в IDE и существующие сценарии сборки и устранят недостатки существующей поддержки магазинов приложений.

Описание

• Поддержка аргументов командной строки, сопоставимая с JNLP (RT-37766)

Сейчас автономные приложения, которые создаёт Packager, обрабатывают только параметры командной строки, переданные при запуске программы из командной строки. (Это только аргументы после имени класса; параметры JVM передаются по другому каналу.) Мы добавим параметры конфигурации, чтобы при отсутствии параметров командной строки вместо них подставлялся набор параметров по умолчанию. Так эти параметры обрабатывает и JNLP; эта поддержка необходима, чтобы создавать самодостаточные приложения из файлов JNLP.

• Обновить нативный лаунчер самодостаточных приложений, чтобы все поддерживаемые платформы (Windows, Mac, Linux) использовали один и тот же нативный исходный код (RT-28833)

Сейчас нативный лаунчер, который использует Packager, написан на C++ для Windows, на Objective-C для Mac и на C для Linux. Исправлять ошибки и добавлять новые возможности очень трудно, потому что ни одну часть исходного кода нельзя использовать совместно на всех трёх платформах. Если и когда будет добавлена Solaris или в будущем любая другая платформа, эта проблема станет экспоненциально сложнее. Чтобы у лаунчера был единый исходный код, платформенно-зависимый код будет реализован в библиотеке функций и классов. Основной код лаунчера будет написан один раз и будет одинаковым для всех платформ, а нужную функциональность для каждой платформы будет обеспечивать платформенно-зависимый код.

• Предоставить удобный API времени выполнения, через который самодостаточные приложения смогут настраивать параметры JVM (RT37767)

Одна из возможностей текущего лаунчера — набор «пользовательских параметров JVM», которые установленное окружение может изменять, чтобы настроить JVM при запуске. Это полезно, например, для размера кучи JVM или для отладки. Однако обращаться к ним приходится через малопонятный механизм передачи с помощью Java preferences API. В рамках этой возможности будут созданы вспомогательные классы, которые станут фасадом между Java-кодом разработчика и нативным лаунчером для обновления пользовательских параметров JVM. Для обратной совместимости текущий способ java.util.prefs будет по-прежнему поддерживаться. Если в лаунчере с единым исходным кодом появится новый механизм, то поддержка обратной совместимости сведётся к однократному чтению и переносу данных, незаметному для приложения; в противном случае она будет работать в обоих направлениях.

• Разрешить пакетам самодостаточных приложений включать несколько программ/точек входа в один и тот же установочный пакет (RT-36118 и RT-34187, косвенно RT-35215)

Некоторые приложения лучше всего развёртывать как набор приложений, например Adobe CS Suite или Microsoft Office. Сейчас в пакете может быть только одно приложение. Разработчики просили возможность размещать несколько приложений в одном пакете. В Windows и Linux это будет реализовано с помощью нескольких лаунчеров (например, word.exe и PowerPoint.exe), использующих одну и ту же JVM. На Mac возможности разместить несколько приложений в одном пакете «.app» ограничены, поэтому на платформе Mac это может не поддерживаться.

• Самодостаточным приложениям для Mac сейчас нужна JRE из JDK; нужно поддержать упаковку автономной JRE для Mac. (RT-35388)

Сейчас существует проблема: Packager для Mac может упаковать только JRE, находящуюся внутри JDK. Хотя нераспространяемые части удаляются, характерная структура файлов JDK остаётся узнаваемой. Это улучшение позволит использовать JRE в качестве упаковываемой среды выполнения с учётом различий в файловой структуре двух пакетов.

• Чтобы решить проблемы автоматизированной сборки, добавить в упаковщик DMG для Mac параметр, убирающий все дополнительные настройки оформления. (RT-37769)

В Mac OS Packager поддерживает сборку DMG с фоновым изображением и символической ссылкой на папку приложений, чтобы пользователь мог легко перетащить пакет приложения для установки. При сборке DMG с фоном и символической ссылкой Packager должен автоматически управлять Finder на машине сборки, а это может вызывать проблемы, если другие приложения прерывают автоматизацию Finder и, например, переводят фокус на другие окна. Особенно это мешает разработчикам, которые выполняют сборку на своих машинах: во время сборки Packager они не могут заниматься другими делами, например читать почту. Если мы добавим возможность создавать простой DMG без фонового изображения и символической ссылки, эта функция будет вызывать меньше проблем и станет удобнее.

• Установщики самодостаточных приложений должны уметь регистрировать ассоциации файлов на нативной платформе в ходе установки. (RT-23918)

JNLP позволяет связывать расширения файлов с конкретной программой JNLP. В самодостаточных приложениях такой возможности нет. Нужно реализовать необходимую логику, чтобы поддержка была как минимум на уровне JNLP.

Тестирование

Сейчас нативный код проверяют только функциональные тесты, которые тестируют продукт целиком. При переходе лаунчера на единый исходный код одновременно будут реализованы нативные модульные тесты, а также дополнительные функциональные тесты для того, что нельзя проверить модульными тестами, например экрана-заставки.

Зависимости

Переход нативного лаунчера на единый исходный код нужно выполнить до того, как мы создадим API для параметров JVM и экран-заставку и обеспечим работу на Mac с JRE, а не только с JDK. Причина в том, что затронутый код из старой версии лаунчеров будет полностью переписан для лаунчера с единым исходным кодом.