J'ai une application de bureau JavaFX (JDK 8) qui utilise Java Web Start pour le déploiement. Les utilisateurs ont Java 8 installé et se connectent simplement à l'URL (une URL publique sur mon serveur AWS Linux) et l'application est téléchargée/démarrée (à l'aide de Web Start). Je peux également facilement mettre à jour l'application en déployant de nouveaux fichiers JAR sur le serveur. Tout fonctionne bien.
Cependant, Oracle a cessé Web Start avec Java 11 et, dans son livre blanc intitulé «Mise à jour de la feuille de route du client Java» de mars 2018, ils recommandent de regrouper un environnement JRE avec l'application («La notion d'application distribuée séparément d'un environnement JRE autonome est, par conséquent, s'estompent rapidement. ”). Je ne peux pas compter sur mes utilisateurs pour rester sur Java 8 pour Web Start, et même s'ils restent à 8, Oracle requiert une licence pour continuer à utiliser Java 8 (ce que je n'ai pas, peut être très coûteux, et je préférerais de toute façon avec la communauté vers JavaFX 11 et OpenJDK).
Je souhaite migrer vers JavaFX 11. J'ai suivi le «Guide d'initiation à JavaFX11» d'OpenJFX ( https://openjfx.io/openjfx-docs/ ), en utilisant OpenJDK 11.0.1 avec le kit de développement JavaFX SDK 11.0.1 de Gluon. (sur Netbeans 10vc2), et ont pu faire fonctionner les exemples d'applications (et il me semble que je devrais être capable de porter mon code JavaFX 8 sur JavaFX 11, assez facilement).
Cependant, c'est là que je suis bloqué pour obtenir des instructions. Comment puis-je intégrer cela à JRE et le déployer pour mes utilisateurs finaux (et fournir des mises à jour d'applications)? Y a-t-il un moyen facile de s’en sortir (ou même un moyen difficile, avec certaines directions/guides)?
Je peux passer des centaines d’heures à écrire des applications bureautiques expressives, riches et utiles dans JavaFX 11, mais que puis-je faire?
Les kits d'outils de déploiement, tels que JWrapper, InstallAnywhere, etc., sont-ils adaptés à cette nouvelle ère de Java 11? Est-ce que Gluon/openjfx.io a peut-être une recommandation ou un guide que j'ai raté? Je n'arrive pas à trouver de recommandations ou de guides de sources réputées sur la façon dont nous, développeurs, qui nous consacrons à l'écriture du code frontal, devons déployer les applications.
Merci pour toute aide ou conseils.
Voici comment cela fonctionne: vous convertissez votre programme en module, puis vous le «liez» à tous les autres modules dont il a besoin.
Le résultat de ce processus de liaison est ce que l’on appelle une image. Une image est en fait une arborescence de fichiers, qui comprend un répertoire bin
avec un ou plusieurs exécutables prêts à être exécutés. Cet arbre correspond à ce que vous distribuez, généralement sous la forme d’un fichier Zip ou tar.gz.
Les étapes sont les suivantes:
jmod
du JDKLa première étape consiste à transformer l'application en un module. Au minimum, cela nécessite la création d'un module-info.Java
en haut de votre arborescence source (c'est-à-dire dans le paquet vide). Chaque module a un nom, qui est souvent identique à un nom de package, mais n’a pas à l’être. Ainsi, votre module-info.Java pourrait ressembler à ceci:
module com.mcs75.businessapp {
exports com.mcs75.desktop.businessapp;
requires Java.logging;
requires transitive javafx.graphics;
requires transitive javafx.controls;
}
Lorsque vous construisez, vous ne spécifiez pas du tout un chemin de classe. Au lieu de cela, vous spécifiez un chemin de module.
Un chemin de module est une liste de répertoires, pas de fichiers. Chaque répertoire contient, sans surprise, des modules. Le répertoire jmods
du JDK est inclus implicitement. Tout ce que vous devez inclure, ce sont des répertoires contenant les modules non JDK dont vous avez besoin. Dans votre cas, cela signifie au moins le JavaFX de Gluon:
javac -Xlint -g -d build/classes --module-path /opt/gluon-javafx/lib \
src/Java/com/mcs75/desktop/businessapp/*.Java
Ensuite, vous créez un pot de la manière habituelle:
jar -c -f build/mybusinessapp.jar -C build/classes .
Un fichier JAR contenant un module-info.class est considéré comme un fichier jar modulaire.
Créer un jmod est généralement un processus simple:
mkdir build/modules
jmod create --class-path build/mybusinessapp.jar \
--main-class com.mcs75.desktop.businessapp.BuinessApplication \
build/modules/mybusinessapp.jmod
Enfin, vous utilisez la commande jlink
du JDK pour tout assembler:
jlink --output build/image \
--module-path build/modules:/opt/gluon-javafx/lib \
--add-modules com.mcs75.businessapp \
--launcher MyBusinessApp=com.mcs75.businessapp
jlink
crée un JRE minimal, qui ne contient que les modules que vous ajoutez explicitement (et les modules requis par ces modules explicites). --add-modules
est l'option requise qui spécifie ce qu'il faut ajouter.
Comme avec les autres outils JDK, --module-path
spécifie les répertoires contenant des modules.
L'option --launcher
permet à l'arborescence des images finales d'avoir un script exécutable supplémentaire dans son répertoire bin
avec le nom donné (la partie précédant l'égalité). Ainsi, MyBusinessApp=com.mcs75.businessapp
signifie "créer un exécutable nommé MyBusinessApp, qui exécute le module com.mcs75.businessapp."
Comme la commande jmod create
incluait une option --main-class
, Java saura quoi exécuter, comme pour déclarer un attribut Main-Class dans un manifeste. Il est également possible de déclarer explicitement une classe à exécuter dans l'option --launcher
si vous le souhaitez.
Ce que vous voulez distribuer est un fichier Zip ou tar.gz de l’arborescence complète du fichier image. L’exécutable que l’utilisateur doit exécuter se trouve dans le répertoire bin
de l’image. Bien sûr, vous êtes libre d'ajouter vos propres exécutables. Vous êtes également libre de le placer dans tout type d’installateur, tant que la structure de l’arborescence des images est préservée.
Un futur JDK aura un outil d’empaquetage pour la création d’installateurs natifs à part entière.
Étant donné que l'image comprend des fichiers binaires natifs, vous devez créer une image pour chaque plate-forme. Évidemment, une option consiste à créer l’image sur un système Linux, puis sur un système Windows, sur un Mac, etc.
Mais vous pouvez également utiliser jmod
et jlink
pour créer des images pour d’autres plates-formes, quel que soit l’endroit où vous construisez.
Quelques étapes supplémentaires sont nécessaires. Tout d'abord, vous aurez besoin des JDK pour ces autres plates-formes. Téléchargez-les sous forme d'archives (Zip ou tar.gz), et non d'installateurs, et décompressez-les dans des répertoires de votre choix.
Chaque JDK définit une chaîne platform. C'est normalement de la forme <os> - <Arch>. La plate-forme est une propriété du module Java.base
; vous pouvez voir n’importe quelle plate-forme du JDK en examinant ce module:
jmod describe path-to-foreign-jdk/jmods/Java.base.jmod | grep '^platform'
Passez cette chaîne de plate-forme à votre commande jmod à l'aide de l'option --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
Enfin, lors de la liaison, vous souhaitez inclure explicitement le répertoire jmods
de l’autre JDK. Jlink n’inclura donc pas implicitement ses propres modules 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
José: Je vois que nous avons le même problème à résoudre (voir ma question à Empaquetage autonome pour une application JavaFX sous Windows: InnoSetup OR javafxpackager? ). Peut-être que l’utilisation du javapackager d’un JDK serait une solution "facile", malgré les nombreux paramètres. Dans mon cas, j’ai réussi à générer un "empaquetage d’applications autonome pour une application JavaFX sous Windows" avec cet outil?