it-swarm.com.ru

Как развернуть приложение JavaFX 11 Desktop с помощью JRE

У меня есть настольное бизнес-приложение JavaFX (JDK 8), которое использует Java Web Start для развертывания. У пользователей установлена ​​Java 8, и они просто переходят по URL-адресу (общедоступному URL-адресу на моем сервере AWS Linux), и приложение загружается/запускается (с помощью Web Start). Я также могу легко обновить приложение, развернув новые JAR-файлы на сервере. Все работает хорошо.

Однако Oracle прекратила Web Start с Java 11, и в своем техническом документе «Обновление дорожной карты клиента Java», март 2018 г., они рекомендуют объединять JRE с приложением («Идея распространения приложения отдельно от автономной JRE: следовательно, быстро исчезает. ») Я не могу полагаться на то, что мои пользователи останутся на Java 8 для Web Start, и даже если они останутся на 8, Oracle требует лицензии для продолжения использования Java 8 (чего у меня нет, может быть очень дорого, и я бы предпочел В любом случае, двигаться вместе с сообществом в направлении JavaFX 11 и OpenJDK).

Я хотел бы перейти на JavaFX 11. Я следовал OpenJFX «Начало работы с JavaFX11» ( https://openjfx.io/openjfx-docs/ ), используя OpenJDK 11.0.1 с Gluon's JavaFX SDK 11.0.1. (на Netbeans 10vc2), и я смог запустить примеры приложений (и, как мне кажется, я мог бы легко перенести свой код JavaFX 8 на JavaFX 11).

Тем не менее, это то, где я застрял для направления. Как связать это с JRE и развернуть на моих конечных пользователях (и предоставить обновления приложений)? Есть ли легкий выход (или даже трудный путь, с некоторыми направлениями/направляющими)? 

Я могу потратить сотни часов на написание выразительных, насыщенных и полезных бизнес-приложений для настольных компьютеров на JavaFX 11, но что мне тогда делать? 

Подходят ли инструменты для развертывания, такие как JWrapper, InstallAnywhere и т.д., В эту новую эру Java 11? Есть ли у Gluon/openjfx.io рекомендации или руководства, которые я пропустил? Я не могу найти какие-либо рекомендации или руководства из авторитетных источников о том, как разработчики, которые сосредоточены на написании кода переднего плана, должны развертывать приложения.

Спасибо за любую помощь или руководство.

8
mcs75

Теперь это работает так: вы конвертируете свою программу в модуль, а затем «связываете» ее со всеми остальными необходимыми модулями.

Результатом этого процесса связывания является то, что известно как изображение. Изображение на самом деле представляет собой файловое дерево, которое включает в себя каталог bin с одним или несколькими готовыми к запуску исполняемыми файлами. Это дерево - то, что вы распространяете, обычно в виде Zip или tar.gz.

Шаги:

  1. Создать модуль-info.Java
  2. Компилировать с путем модуля вместо пути к классу
  3. Создайте банку из классов, как обычно
  4. Конвертируйте jar в jmod с помощью инструмента JDK jmod
  5. Связать этот jmod и модули, от которых он зависит, в образ

Написание дескриптора модуля

Первый шаг - превратить приложение в модуль. Как минимум, для этого требуется создать module-info.Java в верхней части исходного дерева (то есть в пустом пакете). У каждого модуля есть имя, которое часто совпадает с именем пакета, но не обязательно. Итак, ваш module-info.Java может выглядеть так:

module com.mcs75.businessapp {
    exports com.mcs75.desktop.businessapp;

    requires Java.logging;
    requires transitive javafx.graphics;
    requires transitive javafx.controls;
}

Строительство

Когда вы строите, вы вообще не указываете classpath. Вместо этого вы указываете путь к модулю.

Путь к модулю - это список каталогов, а не файлов. Не удивительно, что каждый каталог содержит модули. Каталог jmods JDK включен неявно. Все, что вам нужно, это каталоги, содержащие не-JDK-модули, которые вам нужны. В вашем случае это как минимум означает JavaFX от Gluon:

javac -Xlint -g -d build/classes --module-path /opt/gluon-javafx/lib \
    src/Java/com/mcs75/desktop/businessapp/*.Java

Затем вы создаете банку обычным способом:

jar -c -f build/mybusinessapp.jar -C build/classes .

Файл jar с модулем module-info.class считается модульным jar.

Создание JMOD

Создание jmod - это обычно простой процесс:

mkdir build/modules
jmod create --class-path build/mybusinessapp.jar \
    --main-class com.mcs75.desktop.businessapp.BuinessApplication \
    build/modules/mybusinessapp.jmod

Соединение

Наконец, вы используете команду JDK jlink для сборки всего:

jlink --output build/image \
    --module-path build/modules:/opt/gluon-javafx/lib \
    --add-modules com.mcs75.businessapp \
    --launcher MyBusinessApp=com.mcs75.businessapp

jlink создает минимальную JRE, которая содержит только те модули, которые вы явно добавили (и те модули, которые требуются для этих явных модулей). --add-modules - обязательный параметр, который указывает, что добавить.

Как и в случае с другими инструментами JDK, --module-path определяет каталоги, содержащие модули.

Опция --launcher заставляет конечное дерево изображений иметь дополнительный исполняемый скрипт в каталоге bin с заданным именем (часть перед равными). Итак, MyBusinessApp=com.mcs75.businessapp означает «создать исполняемый файл с именем MyBusinessApp, который выполняет модуль com.mcs75.businessapp».

Поскольку команда jmod create включала параметр --main-class, Java будет знать, что выполнять, точно так же, как объявление атрибута Main-Class в манифесте. Также можно явно объявить класс для выполнения в параметре --launcher, если это необходимо.

Распределительная

То, что вы хотите распространять - это Zip или tar.gz всего дерева файлов изображений. Исполняемый файл, который должен запустить пользователь, находится в каталоге bin образа. Конечно, вы можете добавлять свои собственные исполняемые файлы. Вы также можете разместить это в любом виде установщика, если сохраняется структура дерева изображений.

Будущий JDK будет иметь упаковочный инструмент для создания полноценных собственных инсталляторов.

Поперечное здание

Поскольку изображение включает в себя собственные двоичные файлы, вам нужно будет создать изображение для каждой платформы. Очевидно, что одним из вариантов является создание образа в системе Linux, и снова в системе Windows, и снова на Mac и т.д.

Но вы также можете использовать jmod и jlink для создания образов для других платформ, независимо от того, где вы строите.

Есть только несколько дополнительных шагов, необходимых. Во-первых, вам понадобятся JDK для этих других платформ. Загрузите их как архивы (Zip или tar.gz), а не как установщики, и распакуйте их в каталоги по вашему выбору.

Каждый JDK определяет строку platform. Обычно это имеет вид <os> - <Arch>. Платформа является свойством модуля Java.base; Вы можете увидеть любую платформу JDK, изучив этот модуль:

jmod describe path-to-foreign-jdk/jmods/Java.base.jmod | grep '^platform'

Передайте эту строку платформы вашей команде jmod, используя опцию --target-platform:

mkdir build/modules
jmod create --target-platform windows-AMD64 \
    --class-path build/mybusinessapp.jar \
    --main-class com.mcs75.desktop.businessapp.BuinessApplication \
    build/modules/mybusinessapp.jmod

Наконец, при связывании вы хотите явно включить другой каталог JDK jmods, чтобы jlink не включал неявно свои собственные модули JDK:

jlink --output build/image \
    --module-path path-to-foreign-jdk/jmods:build/modules:/opt/gluon-javafx/lib \
    --add-modules com.mcs75.businessapp \
    --launcher MyBusinessApp=com.mcs75.businessapp
7
VGR

Хосе: Я вижу, что нам нужно решить одну и ту же проблему (см. Мой вопрос в Упаковка автономных приложений для приложения JavaFX в Windows: InnoSetup OR javafxpackager? ). Возможно, использование javapackager из JDK было бы «простым» решением, несмотря на многочисленные параметры. В моем случае с помощью этого инструмента мне удалось создать «Пакет автономных приложений для приложения JavaFX в Windows»?

0
Pascal DUTOIT