Discussion :

[Vahia]

Bonjour à tous !

Je suis en grosse galère et je ne sais plus quoi faire.
Il y a quelques mois j'ai créé un jeu dont l'interface graphique a été réalisée à l'aide de Swing. Une fois exporté, le jeu a fonctionné nickel. Du coup je me suis mis sur un second jeu mais ce coup-ci en utilisant JavaFX pour l'interface graphique. Une fois passées les complications d'installation et configuration de JavaFX j'ai réussi à créer le jeu. Il fonctionne plutôt bien sous eclipse (il me reste quelques détails à régler).
J'ai voulu l'exporter pour le tester mais tout d'abord j'ai eu un message d'avertissement : "VM arguments will not be part of the runnable JAR. Arguments can be passed on the command line when launching the JAR". Et effectivement, j'ai passé des arguments à mon projet pour qu'il fonctionne dans eclipse : "--add-modules javafx.controls,javafx.fxml". Ensuite, le jar ne s’exécute tout simplement pas...

Du coup je suis perdu et je me pose pas mal de questions. Tout d'abord, dans la mesure où JavaFX n'est plus inclus dans le JDK, une personne ne possédant qu'un simple JRE pourra-t-elle exécuter mon jeu ? Parce que si pour exécuter un jar il faut installer le JRE puis JavaFX, ça devient un peu lourd quand même.

Peut-on embarquer les librairies JavaFX dans l'exportation du projet ? (ça résoudrait peut-être mon problème)

Dois-je exporter mon jeu en .exe via ant et Inno Setup ? J'ai essayé mais quand, après avoir rempli le fichier build.fxbuild, je clique sur "generate ant build.xml only", il ne se passe rien.

Personnellement ce que je préfèrerais faire c'est créer un jar exécutable qui contiendrait tout ce qu'il faire pour être exécuté avec un simple JRE. Mais je ne vois pas comment faire...

Je vous remercie d'avance pour votre aide.

[bouye]

Double cliquer sur des JAR pour lancer un programme est problématique :

• souvent des gestionnaires d'archives vont remplacer la prise en charge des fichiers JAR pour les ouvrir directement (puisque ce sont des fichiers ZIP)
• l'anti-virus peut éventuellement bloquer la prise en charge de ces fichiers pour éviter des programmes malicieux.
• impossible de mettre des arguments

Donc en général on va utiliser un lanceur, un fichier script (.bat sous Windows) ou un exec natif qui va faire le lancement du programme et généralement on utilisera aussi une JVM embarquée propre au programme pour éviter de taper dans une éventuelle JVM système (de plus en plus rare, souvent pas a la bonne version et aussi pour éviter des soucis de securite)

• Pour commencer et tester un simple fichier .bat fera l'affaire. Ca a le soucis de laisser ouverte une fenetre de ligne de commande qui, si elle est fermée par l'utilisateur, fermera également le programme. Au moins ça permet de tester les bons arguments.
• javapackager (JDK 8, 9 et 10) permet de lancer une application sur une JVM embarquée avec un fichier de conf (qui donne le nom du JAR principal et les arguments de lancement de la JVM). Pas de support des applications modulaires.
• jlink (JDK 9+) permet de générer une JVM réduite mais avec des lanceurs sous forme de script (.bat pour Windows). Pas de support des applications non-modulaires.
• jpackage (JDK 14+) est sensé remplacer javapackager
• WinRun4J (et aussi sur GitHub) permet de créer des lanceurs natifs avec JVM embarquée ou système pour Windows. Ça a pas été mis a jour depuis longtemps...
• Launch4j permet de créer des lanceurs natifs avec JVM embarquée ou système pour Windows. La dernière version date de 2018.

[Vahia]

Merci Bouye pour ta réponse.

Je vais regarder du côté de javapackager parce que ça me tente bien. Le top je trouve c'est launch4j. J'avais essayé il y a quelques temps et ça n'avais pas marché. Je vais refaire un essai.

Le truc qui me déroute c'est que mon premier jeu (java swing) s'exécute très bien via son jar exécutable alors que mon second jeu (javafx) lui ne s'exécute pas. Bien évidemment je parle sur le même ordinateur.
Quand je clique droit sur le jar et que je fais ouvrir avec..., j'ai 2 choix : Winrar ou java platform qqchose... Je clique sur java machin et il ne se passe absolument rien...

[bouye]

Oui mais quelle JRE ? Quelle version de Java ? Quelle version de JavaFX ?

A partir du JDK 11 JavaFX n'est plus dans le JDK et donc il faut utiliser des paramètres supplémentaires sur la ligne de commande pour pointer sur les bonnes bibliothèques. Pire avec les applications modulaires il faut aussi lister les modules... donc un simple clic sur un JAR ne fonctionnera pas. Swing ca continue a marcher car lui il est toujours dans le JDK.

De toute manière désormais il y a plus de JRE donc cette méthode n'est pas viable.

Lance ton programme en ligne de commande (java -jar [...]) qu'on sache deja quelle est l'erreur qui est générée !

[Vahia]

Avec la commande java -jar monjeu2.jar j'ai ce message d'erreur :

Error : JavaFX runtime components are missing, and are required to run this application

Du coup j'ai modifié la commande : java -jar --add-modules javafx.controls,javafx.fxml -jar monjeu2.jar et là j'ai ce message :

Error occured during initialization of boot layer java.lang.module.FindException: Module javafx.controls not found

[Vahia]

ça y est, je me rappelle pourquoi je n'avais pas réussi à utiliser Lanch4j.
Juste après l'avoir installé, au premier lancement j'ai ce message d'erreur : "This application requires a Java runtime Environment 1.6.0 - 1.8.9"...

[bouye]

Il doit manquer --module-path=<chemin vers le repertoire lib de l'OpenJFX>, et il faudra il faudra ces fichiers JAR copier dans un sous-répertoire de ton application puisque tu va pas demander a tes utilisateurs d'installer le kit de dev JavaFX sur leur PC.

[Vahia]

Désormais j'ai l'erreur "Accès refusé".
J'ai exécute l'invite de commande en tant qu'administrateur et j'ai copié le dossier de javafx-sdk ailleurs que sur C: car il me semble que tout ce qui est à la racine de C: possède des restrictions d'accès.
Mais ça change rien.

[bouye]

En effet t'es pas sensé faire ta tambouille sur la racine de C: . Crée toi un répertoire de travail (sans espace dans le nom, ça sera plus facile) et bosse dedans dans un sous-répertoire associé au projet.

Reprenons depuis le début :

• Il te faut un JDK (quelle version ?), soit un des installeurs d'Oracle, soit le ZIP de l'OpenJDK, voir même une autre distrib
• Il te faut le SDK JavaFX (quelle version ?)
• Tu mets le JDK dans un répertoire dédié (soit via l'installeur, soit en dezippant)
• Tu met le SDK JavaFX dans un répertoire dédié.
• Tu définis ta variable environnement JAVA_HOME en pointant sur le répertoire ou se trouve le JDK (tu sais comment faire sur Windows ?)
• Tu rajoute le chemin %JAVA_HOME%\bin sur ton PATH (même question ?)
• Tu ouvres une nouvelle boite de dialogue et tu fais :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  java --version

  ce qui devrait te retourner la version de Java de ton JDK

[Vahia]

Tu as complètement raison, reprenons du début.

- J'ai téléchargé et installé le dernier JDK du site d'Oracle (JDK 13.0.1)
- Pour le SDK JavaFX j'ai téléchargé la version 13.0.1
- Le JDK est dans C:\Program Files\Java\jdk-13.0.1
- Le SDK est dans C:\Prog\OpenJFX\javafx-sdk-13.0.1
- La variable JAVA_HOME n'existait pas. Je l'ai créé dans les variables d'environnement/Variables Système (et non variables utilisateur) en lui mettant le chemin du JDK indiqué plus haut.
- Dans le variable système PATH existante j'ai ajouté ";%JAVA_HOME%\bin" à la suite.

Un petit reboot.

- Dans l'invite de commande, la commande java --version me renvoie : " 'Java' n'est pas reconnu en tant que commande interne ou externe, un programme exécutable ou un fichier de commandes."

[bouye]

Normalement suite à la modification du PATH cette erreur ne devrait pas se produite. Vérifie la valeur de PATH et que le chemin spécifié dans JAVA_HOME, notamment le fait d'avoir peut-être oublié de mettre des " autour des chemins contenant des espaces.

[Vahia]

J'ai finalement trouvé une petite erreur de frappe.

Désormais, avec "java -version" j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
java 13.0.1 2019-10-15
Java(TM) SE Runtime Environment (build 13.0.1+9)
Java HotSpot(TM) 64-Bit Server VM (build 13.0.1+9, mixed mode, sharing)

Du coup j'ai essayé de lancer mon jeu avec la commande : "java -jar --module-path=<C:\Prog\OpenJFX\javafx-sdk-13.0.1\lib> --add-modules javafx.controls,javafx.fxml -jar monjeu2.jar".
ça me renvoi "Accès refusé".
(Je précise que l'invite de commande est exécutée en tant qu'administrateur).

[bouye]

Alors correction, suite a une erreur de ma part c'est --module-path <chemin vers le repertoire lib de l'OpenJFX>, sans le '=' donc et le '<' et '>' c'est pour dénoter la partie a replacer par la bonne valeur, donc il ne faut pas les mettre.

Donc, dans ton cas cas devrait plutôt être --module-path C:\Prog\OpenJFX\javafx-sdk-13.0.1\lib (penser aux " quand il y a des espaces dans le chemin, pas besoin ici puisqu'il y en a pas).

[Vahia]

C'est bon, ça s'ouvre correctement.
Donc si j'ai bien compris ça nous rassure sur le fait que le .jar est fonctionnel.
Du coup il reste à trouver un moyen de pouvoir le lancer autrement qu'en lignes de commande c'est ça ?
Et aussi un moyen d'embarquer les librairies javafx, non ?!

[bouye]

C'est bien cela,

Pour du JDK 8, 9 et 10 la solution est assez simple, utiliser javapackager avec un IDE qui le prend bien en charge (ex: Netbeans 8, le dernier édité par Oracle), ça marche très bien.

Pour des JDK + JavaFX plus récent, il y a jpackage (dispo dans une prérelease du JDK14); Là je suis en train de tester la preview de jpackage en me basant sur le bouquin The Definitive Guide to Modern Java Clients with JavaFX: Cross-Platform Mobile and Cloud Development dont les auteurs sont à peu près toutes les sommités (13) existantes de JavaFX et qui a une section dédiée sur ça.
Le soucis c'est que j'arrive bien à créer une distribution, MAIS que jpackage se repose sur jlink et donc il est uniquement capable de préparer une distribution avec des fichiers jmod. Donc y a aucun soucis pour JavaFX (les fichiers jmod sont dispo chez Gluon avec le SDK) mais il est totalement incapable de se débrouiller avec des JAR non-modulaires (le reste des libs dont dépent mon programme de test) et oublie donc de les recopier ou de les intégrer. Donc bref je continue de chercher comment intégrer tout ça correctement.

Ensuite le bouquin aborde une manière de faire via Graddle (partie sans doute écrite par Vos) et une autre sur GraalVM mais j'ai pas eut le temps d'aborder ces parties vu que je suis encore bloqué sur l'usage de base de jpackage.

[bouye]

Une petite mise a jour, je suis passe sur la derniere Early Access du JDK 14 (auparavant je testais la version preview de jpackage qui datait de septembre il me semble). Outre quelques arguments qui sont passes a la trappe (ex : -o ou --output pour spécifier le répertoire de sortie -pourquoi ? Aucune idée-), il semble que jlink (qui est invoque par jpackage) supporte encore moins les applications non-modulaires et donc ce qui fonctionnait hier (c-a-d dire la generation de l'image et du lanceur -ca plantait après a l’exécution a cause des JARS non modulaires introuvables-) plante désormais a la génération avec un jlink failed with: Error: automatic module cannot be used with jlink: java.activation from file:///C:/fabriceb/Devel/Java/lib/Gluon/Connect/2.0.1/javax.activation-api-1.2.0.jar.

Sont penibles c'est pas bien complique qu'un auto-module (un JAR non-modulaire) se comporte comme un module...

Bref, l'aventure continue....

[Vahia]

C'est dingue que ce soit autant la galère pour exporter un projet javafx... On passe autant de temps à programmer qu'à essayer d'exporter.
En faisant l'UI avec Swing c'est tout de même nettement plus simple...

J'ai entendu parler de WinRun4j pour eclipse (j'ai programmé sous eclipse), tu sais si c'est bien et si ça fonctionne ?

[Mickael_Istria]

C'est dingue que ce soit autant la galère pour exporter un projet javafx... On passe autant de temps à programmer qu'à essayer d'exporter.
En faisant l'UI avec Swing c'est tout de même nettement plus simple...

Bof, c'est pas dit: depuis que le JDK est modulaire, il y a des distributions de Java qui n'embarquent pas le module java.desktop (et donc Swing) par defaut.
Au final, le plus simple est de partir de l'idee qu'on n'est jamais sur de quel API graphique Java il y a de pre-installee et de faire en sorte que son programme livre les API qu'il utilise au cas ou. Dans ce cas, Swing est un choix discutable et il devient clairement plus interessant de toujours prendre JavaFX ou SWT qui ont plus de qualites.

[bouye]

En tout cas moi perso c'est la galère depuis le JDK 9. Pas mal d'IDE supportent mal ou carrément pas du tout jlink et la doc est plutôt inexistante de ce coté-là. javapackager qui marchait très bien pour les app non-modulaires jusqu'au JDK 10 disparaît du jour au lendemain sans prévenir et sans que personne ne title chez l'OpenJDK qu'il y a plus rien pour d'officiel pour empaqueter les exécutables à partir du JDK 11. Du coup les gens de l'OpenJFX poussent pour le développement de jpackage mais à cause des sorties rapides du JDK, l'outil se retrouve propulsé au JDK 13 puis 14... et GraalVM en est également toujours un peu à un stade prototypal donc la doc est pas bien présente ou fluctue.
Quand à Maven et Gradle je cherche encore comment aborder le sujet.

Bref alors qu'au JDK 8 j'avais toute une pile d'outils qui marchait super pour créer et empaqueter facilement des applications desktop, ben depuis le JDK 9 tout est cassé et marche pas bien même en suivant les exemples, blogs et bouquins des meilleurs experts sur le sujet. J'en veux pour preuve le livre que j'ai mentionné plus haut qui est fraîchement sorti en novembre dernier et a été écrit sous les JDK 9 à 12... avec dedans 1-2 exemples qui marchent plus avec le JDK 13... et je ne parle pas de la partie sur jpackage qui est basée sur la version early access et donc ne s'applique plus sur la version presque finale que j'ai en ce moment sous la main.............



C'est pas comme si toutes les libs Java étaient soudainement devenue modulaires et fournies avec des jmods du jour au lendemain. C'est très loin d'être le cas et souvent on a des super-lib legacy qui fonctionnent toujours très bien sur les JDK modernes mais qui sont pas modulaires du tout, pas signées etc. donc du coup ca devient assez galère de les intégrer et ce à cause de outils officiels qui manquent de flexibilité, du manque de doc, etc.

[bouye]

A noter que, pour ceux qui sont réfractaires au SDK séparé, le JDK distribué par BellSoft (version "regular") contient toujours JavaFX (la version "light" en est privée), ce qui peut rendre les dev plus faciles (sans pour autant régler le soucis du packaging natif des JAR tiers non-modulaires).