Programme qui fonctionne sous eclipse mais pas une fois exporté

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.

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.

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...

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 !

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

Citation:

---

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 :

Citation:

---

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

---

ç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"...

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.

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.

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:

  ---

  java --version

  ---

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

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."

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.

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

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

Code:

---

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).

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).

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 ?!

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.

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....

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 ?

Citation:

---

Envoyé par 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...

---

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.

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.............

:calim2:

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.

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).

JPackageScriptFX, un projet contenant un ensemble de scripts pour empaqueter une application FX dans un lanceur natif.

Je comprends mieux ceux qui critiquent Java pour sa lourdeur... C'est pénible de galérer pour des histoires d'export...

J'ai testé WinRun4J avec Eclipse mais ça ne marche pas. J'ai un message d'erreur : "Failed to find Java VM". C'est pénible...
Je crois que je vais repasser en JDK10 et utiliser NetBeans et Javapackager.

En attendant de mettre la main sur javapackager (que je n'ai pas encore réussi à trouver), je me dis que je pourrais peut-être créer un dossier dans lequel je mets mon jar exécutable et les 2 librairies dont j'ai besoin (javafx.fxml et javafx.controls).
C'est pas très propre j'en convient mais en désespoir de cause...

Par contre, comment puis-je faire pour que mon jar aille chercher les librairies dont il a besoin dans le dossier commun ? (sachant que j'aimerais distribuer ce dossier don sont chemin absolu ne sera jamais le même)

Question (peut-être) bête : vu que .jar est un extension d'archive. Si j'intègre mes 2 librairies javafx dans le jar avec WinRAR (ou autre), y'a-t-il un moyen que mon jar s'exécute correctement puisqu'il possède désormais toutes les librairies ?

Citation:

---

Question (peut-être) bête : vu que .jar est un extension d'archive. Si j'intègre mes 2 librairies javafx dans le jar avec WinRAR (ou autre), y'a-t-il un moyen que mon jar s'exécute correctement puisqu'il possède désormais toutes les librairies ?

---

J'ai un peu regardé le contenu des différents jar (mon exécutable et les 2 librairies en question). Ce qui me surprend c'est que tous les fichiers contenus dans les 2 librairies sont aussi présents dans mon jar exécutable.
C'est normal ? Si les librairies sont présentes alors pourquoi ça ne s’exécute pas ?

Salut,

Citation:

---

Envoyé par Vahia

Question (peut-être) bête : vu que .jar est un extension d'archive. Si j'intègre mes 2 librairies javafx dans le jar avec WinRAR (ou autre), y'a-t-il un moyen que mon jar s'exécute correctement puisqu'il possède désormais toutes les librairies ?

---

Il ne suffit d'ajouter un JAR dans un JAR pour qu'il soit dans le classpath (c'est ça qui compte). Cf https://docs.oracle.com/javase/tutor...r/downman.html

Ensuite, si ton JAR est signé, ajouter des fichiers dedans va le rendre invalide. C'est un peu fait exprès pour justement que personne ajoute ou modifie des trucs dans un jar, en particulier quand il est diffusé.

Par ailleurs, JavaFX c'est un peu particulier aussi. Y'a que des JARs ? Y'a pas de bibliothèques natives par exemple ?

Oui il y a une partie native. Faut que je ressorte le JDK 10 pour refaire des tests.
Note : il faut le JDK 10 d'Oracle, pas celui de l'OpenJDK (qui contient ni JavaFX, ni javapackager)

pour faire quelques tests j'ai rallume le Apache NetBeans 11 pour voir si ca marche comme sous Oracle NetBeans 8.2 (note : j'utilise IDEA depuis un certains temps). Bien qu'il soit toujours possible de cocher la case clic droit sur le projet -> Projet Properties -> Deployment -> Enable Native Packaging Actions in Projet Menu, puis de faire clic droit sur le projet -> Package as -> Image only

• Dans le cadre d'un projet NetBeans Java-only, même si on a fait une application FX qui marche dans l'IDE, le packaging crash avec une erreur ANT:
  
  Code:

  ---

  1 2 3 4

  Warning: Nashorn engine is planned to be removed from a future JDK release Warning: Nashorn engine is planned to be removed from a future JDK release <path to project>\nbproject\build-native.xml:519: typedef class com.sun.javafx.tools.ant.FXJar cannot be found using the classloader AntClassLoader[]

  ---

• Dans le cadre d'un projet NetBeans JavaFX, la tache de packaging se lance sans erreur... mais aucune idee de l'endroit ou il va stocker les fichiers... (en tout cas pas dans le projet)

Bref, revenons a nos moutons, grâce a mon IDE, j'ai mon application simple non-modulaire JavaFX compilée sous forme d'un JAR ainsi que les dépendances (ici Apache POI).

test/strings.properties

Code:

---

1 2	button.hello.text=Say 'Hello' button.open.text=Open

---

test/styles.css

Code:

---

1 2 3 4 5 6

.root { } .vbox { -fx-alignment: center; -fx-spacing: 10px; }

---

test/test.fxml

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

<?xml version="1.0" encoding="UTF-8"?>   <?import java.lang.*?> <?import java.util.*?> <?import javafx.scene.*?> <?import javafx.scene.control.*?> <?import javafx.scene.layout.*?>   <StackPane id="StackPane" prefHeight="400.0" prefWidth="600.0" xmlns:fx="http://javafx.com/fxml/1" fx:controller="test.TestController"> <children> <VBox styleClass="vbox"> <children> <Label id="javaVersionLabel" fx:id="javaVersionLabel"/> <Label id="javaFXVersionLabel" fx:id="javaFXVersionLabel"/> <Button id="helloButton" fx:id="helloButton" text="%button.hello.text" onAction="#onHelloAction"/> <Button id="openButton" fx:id="openButton" text="%button.open.text" onAction="#onOpenAction"/> </children> </VBox> </children> </StackPane>

---

test.Main

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

package test;   import java.io.IOException; import java.net.URL; import java.util.Optional; import java.util.ResourceBundle; import java.util.logging.FileHandler; import java.util.logging.Level; import java.util.logging.Logger; import javafx.application.Application; import javafx.fxml.FXMLLoader; import javafx.scene.Parent; import javafx.scene.Scene; import javafx.stage.Stage;   public final class Main extends Application {   static final Logger LOGGER = Logger.getLogger(Main.class.getName());   public static void main(String[] args) throws IOException { final var fileHandler = new FileHandler("test.log"); LOGGER.addHandler(fileHandler); LOGGER.log(Level.INFO, "Start"); launch(args); }   public void start(final Stage stage) throws IOException { final var bundle = ResourceBundle.getBundle("test/strings"); final var fxmlLoader = new FXMLLoader(); fxmlLoader.setResources(bundle); Optional.ofNullable(getClass().getResource("test.fxml")) .ifPresent(fxmlLoader::setLocation); final var root = fxmlLoader.<Parent>load(); final var scene = new Scene(root); Optional.ofNullable(getClass().getResource("styles.css")) .map(URL::toExternalForm) .ifPresent(scene.getStylesheets()::add); stage.setTitle("Test"); stage.setWidth(600); stage.setHeight(400); stage.setScene(scene); stage.show(); } }

---

test.TestController

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

package test;   import java.io.File; import java.io.IOException; import java.util.logging.Level; import java.util.Optional; import javafx.fxml.FXML; import javafx.scene.control.Button; import javafx.scene.control.Label; import javafx.stage.FileChooser; import org.apache.poi.openxml4j.exceptions.InvalidFormatException; import org.apache.poi.xssf.usermodel.XSSFWorkbook;   public class TestController {   @FXML private Label javaVersionLabel; @FXML private Label javaFXVersionLabel; @FXML private Button openButton;   public void initialize() { Main.LOGGER.entering(TestController.class.getName(), "initialize"); javaVersionLabel.setText(String.format("Java: %s", System.getProperty("java.version"))); javaFXVersionLabel.setText(String.format("JavaFX: %s", System.getProperty("javafx.version"))); }   @FXML private void onHelloAction() { Main.LOGGER.log(Level.INFO, "onHelloAction"); System.out.println("Hello World!"); }   @FXML private void onOpenAction() { Main.LOGGER.log(Level.INFO, "onOpenAction"); final var dialog = new FileChooser(); dialog.getExtensionFilters().add(new FileChooser.ExtensionFilter("Excel 2007 files", "*.xlsx")); Optional.ofNullable(dialog.showOpenDialog(openButton.getScene().getWindow())) .ifPresent(this::openFile); }   private void openFile(final File file) { Main.LOGGER.log(Level.INFO, "openFile"); try (final var workbook = new XSSFWorkbook(file)) { System.out.printf("Excel compatibility: %s%n", workbook.getSpreadsheetVersion()); } catch (IOException | InvalidFormatException ex) { Main.LOGGER.log(Level.SEVERE, null, ex); } } }

---

Les JAR en dépendances sont commons-collections4-4.3.jar, commons-compress-1.18.jar, poi-4.1.0.jar, poi-ooxml-4.1.0.jar, poi-ooxml-schemas-4.1.0.jar, xmlbeans-3.1.0.jar. Le JAR de mon application se trouve dans le sous-repertoire dist de mon projet.


Etape 0 : s'assurer que le JDK 10 est dans le PATH lorsqu'on lance la commande java ou javapackager.

Etape 1 : recopier toutes les dependances dans un sous-repertoire lib du repertoire dist.

Etape 2 : extraire (n'importer quel utilitaire ZIP) le fichier META-INF/MANIFEST.MF hors du JAR de l'application

Etape 3 : ouvrir META-INF/MANIFEST.MF dans un éditeur de texte et rajouter la ligne suivante :

Code:

---

Class-Path: lib/commons-collections4-4.3.jar lib/commons-compress-1.18.jar lib/poi-4.1.0.jar lib/poi-ooxml-4.1.0.jar lib/poi-ooxml-schemas-4.1.0.jar lib/xmlbeans-3.1.0.jar

---

Etape 4 : écraser (n'importer quel utilitaire ZIP) le fichier META-INF/MANIFEST.MF dans le JAR de l'application par la version qu'on vient d’éditer

A ce niveau désormais il devrait être possible de lancer le JAR de l'application en faisant java -jar <nom du jar>, normalement elle devrait démarrer sans aucun problème.

Note : ici est le bon moment pour intercaler une étape de signature des fichiers JAR.

Etape 5 : à la racine du projet exécuter la commande suivante javapackager -deploy -native image -appclass test.Main -outdir redist -srcdir dist pour créer une image native.
Cette commande fera son possible pour determiner quels modules sont nécessaires à notre application (ex: lors de mes tests initiaux j'utilisais pas FXML et donc le module javafx.fxml n’était pas inclus dans l'image). Cette commande créera un repertoire redist contenant un repertoire Main qui est notre application native (ps : il doit y a voir un flag pour changer le nom de l'application). Ce repertoire Main contient 2 repertoires :

• app est une copie du contenu du repertoire dist d'origine avec, en plus, un fichier de configuration supplémentaire. C'est dans ce répertoire que le fichier log créé par l'application apparaîtra.
• runtime contient une copie de la JVM JDK-10 avec les modules appropriés.

A la racine de Main on trouvera des fichiers nécessaires au lanceur natif, ici des DLLs, un .EXE windows et une icone par défaut (probablement customisable via un flag). Si tout se passe bien, le programme se lance lorsqu'on double-clique sur le .EXE. Si on a omis l'etape 4, le programme ne se lancera pas car les dépendances de Apache POI ne sont pas trouvées, cependant le crash de l'application est silencieux et je ne sais pas trop comment capturer ca dans des logs Windows.

Je n'ai pas testé plus en avant mais il existe des flag de javapackager pour créer un JAR (à partir de .CLASS precompilées je pense) et de spécifier les dépendances sur le CLASSPATH (ce qui évite d'éditer manuellement le fichier MANIFEST.MF). Et il y a aussi des flags pour créer un installeur ou un fichier MSI si Wix est installé sur Windows.

Exécuter la commande de javapackager sur Linux permet de créer un lanceur natif Linux (resp repertoire APP sur macOS). De même qu'il y a des flags pour créer des fichiers DEB ou RPM sous Linux (resp PKG ou DMG sur macOS).

Merci beaucoup pour vos réponses !

J'ai ouvert le jar avec WinRAR. J'ai ajouté un dossier "lib" dans lequel j'ai placé les fichiers javafs.fxml.jar et javafx.controls.jar.
Dans le manifest, j'avais "Class-Path : .". J'ai modifié la ligne en : "Class-Path : lib/javafx.controls.jar lib/javafx.fxml.jar"

Dans l'invite de commande, avec la commande java -jar monJar j'ai une nouvelle erreur : "Error: JavaFX runtime components are missing, and are required to run this application."
Cela vient-il du fait que le JDK présent sur mon système est le JDK13 ? Pourtant si je fournis les librairies la version du JDK devient moins importante non ?!

J'ai remarqué que quand, au moment d'exporter mon projet, je choisis "package required libraries into generated jar" au lieu de "extract required libraries into generated jar", eclipse me place tous les jar du sdk javafx à la racine de mon projet. De plus, il modifie le manifest qui devient :

Code:

---

1 2 3 4 5 6 7

Manifest-Version: 1.0 Main-Class: org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader Rsrc-Class-Path: ./ javafx.base.jar javafx.graphics.jar javafx.media.jar javafx.swing.jar javafx.web.jar javafx-swt.jar javafx.controls.jar jav afx.fxml.jar Rsrc-Main-Class: application.Main Class-Path: .

---

Cependant ça ne fonctionne toujours pas.
Quand modifie la dernière ligne en "Class-Path : javafx.fxml.jar javafx.controls.jar" et que je lance le jar de mon jeu dans l'invite de commande j'ai pas mal d'erreurs qui sortent :

Code:

---

1 2 3 4 5 6 7 8 9 10

Graphics Device initialization failed for : d3d, sw Error initializing QuantumRenderer: no suitable pipeline found java.langRuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance<QuantumRenderer.java:280> at com.sun.javafx.tk.quantum.QuantumToolkit.init<QuantumToolkit.java:244> at com.sun.javafx.tk.Toolkit.getToolkit<Toolkit.java:260> at com.sun.javafx.application.PlatformImpl.startup<PlatformImpl.java:267> // Je passe pas mal de lignes... Caused by: java.lang.RuntimeException: No toolkit found // Encore quelques lignes...

---

Vu que je suis en mode désespéré/test de tout et de rien pour que ça finisse par fonctionner, j'ai de nouveau essayé d'éxecuter mon jeu dans l'invite de commande via "java -jar --module-path(...) --add-modules javafx.fxml,javafx.controls -jar monJar.jar".
Le jeu se lance bien et son fonctionnement est correct mais étrangement j'ai perdu toutes les images de fond. J'ai un fond blanc au lieu des images qu'il devrait y avoir...
C'est décidément de plus en plus obscur...

Houla je rappelle juste que le test que j'ai fait est avec le JDK 10 (celui d'Oracle incluant JavaFX) et non pas 13 (JDK de Oracle ou OpenJDK avec OpenJFX -binaires de gluon en séparé-) sans inclure quoi que ce soit d'autre dans le JAR a part la modification de la ligne Class-Path. Pour autre chose il faudra faire plus de tests mais j'ai pas énormément de temps pour cela.

Digression : rapide test avec le Liberica JDK 13.0.2 de BellSoft, qui contient JavaFX 13.0.2, avec Intellij IDEA. D'un coté l'éditeur de code d'IDEA trouve bien que JavaFX est dans le JDK et donc ne fait pas d'erreur lorsqu'on tape le code mais d'un autre il est incapable de compiler le programme en disant qu'il ne peut pas trouver les modules nécessaires (javafx.graphics, javafx.controls et javafx.fxml), même en mettant les flags additionnels --module-path et --add-modules aux endroits qui vont bien. Une petite exploration de Liberica montre qu'il contient bien les JMOD de JavaFX mais par les JAR, ceci explique peut-être cela.

Un autre soucis est que BellSoftg a pas signé numériquement ses exécutable et donc, dans mon cas, mon anti-virus a mis java.exe en quarantaine le temps de l'envoyer pour analyse à sont éditeur... :calim2:

Retour sur mon programme de test. Nous reprenons le code à l'identique mais cette fois-ci nous quittons Apache NetBeans 11 et le Oracle JDK 10 pour la dernière version d'IDEA avec OpenJDK 13.0.2 et JavaFX 13.0.2. Le code est strictement identique à ce que j'ai posté plus haut mais nous allons passer l'application en modulaire en rajoutant le fichier suivant :

module-info.java

Code:

---

1 2 3 4 5 6 7 8 9

module test { requires java.logging; requires javafx.graphics; requires javafx.fxml; requires javafx.controls; requires poi.ooxml; exports test; opens test to javafx.fxml; }

---

Etape 1 : vérifier que tout se compile et se lance bien dans IDEA après avoir rajouté les dépendances qu'il faut.

Pièce jointe 533671

Etape 2 : clic droit sur le projet -> Open Module Settings -> Artifacts -> + -> JAR -> Empty et on définit un nouvel artefact dans IDEA pour produire un JAR. On rajoute dans le JAR les fichiers produits par la compilation du projet. Dans cette étape j'ai décidé de conserver l'optique précédente ne ne pas intégrer les dépendances directement dans le JAR mais les placer dans un sous-répertoire lib. Ici IDEA me permet de spécifier un fichier META-INF/MANIFEST.MF externe mais aussi de spécifier manuellement la sections Class-Path comme je le veux donc ca évite de devoir bidouiller le manifest après la création du JAR.

Pièce jointe 533673

META-INF/MANIFEST.MF

Code:

---

1 2 3

Manifest-Version: 1.0 Class-Path: lib/commons-collections4-4.4.jar lib/commons-compress-1.19.jar lib/poi-4.1.1.jar lib/poi-ooxml-4.1.1.jar lib/poi-ooxml-schemas-4.1.1.jar lib/xmlbeans-3.1.0.jar Main-Class: test.Main

---

Etape 3 : aller dans Build -> Build Artifacts... -> <nom de l'artefact> -> build. Typiquement le JAR sera produit dans out\artifacts\<nom du projet>\<nom de l'artefact>.jar.

Etape 4 : créer un répertoire lib dans out\artifacts\<nom du projet>\ et y recopier toutes les dépendances JAR (ici Apache POI).

Etape 5 : ouvrir une ligne de commande dans out\artifacts\<nom du projet>\ et vérifier qu'on peut correctement lancer le projet en faisant java --module-path <chemin vers le SDK JavaFX 13.02>\lib --add-modules javafx.fxml,javafx.controls -jar testpackaging.jar.

Pièce jointe 533683
Ici le programme tourne sur le JDK 13.0.2

A nouveau ici est une bonne étape pour signer les JAR si besoin.

Etape 6 : récupérer et installer le JDK 14 Early Access. Il faut également récupérer les fichiers JMODS (pour Windows) de JavaFX chez Gluon.

Etape 7 : créer une image d'application avec la ligne de commande suivante :

Code:

---

<chemin vers le JDK 14>\bin\jpackage.exe --type app-image --input . --name <nom de l'application> --main-jar <nom de l'artefact>.jar --module-path <chemin vers les fichiers JMODS de JavaFX 13.02> --add-modules javafx.fxml,javafx.controls --dest redist

---

Cela créera un répertoire redist avec une structure similaire à celui construit précédemment sous le JDK 10 en utilisant javapackager, avec un EXE qui permet de lancer le programme.

Il reste un problème : lorsqu’on lance ce programme (celui écrit plus haut) il tourne en fait sur le JDK 14 EA au lieu du JDK 13.0.2, en effet jpackage a décidé d'empaqueter le JDK 14 avec lequel il est fourni. Je ne sais pas s'il y a un flag qui lui permettrai de fonctionner avec le JDK 13.0.2 à la place.

Pièce jointe 533685
Ici le programme tourne sur le JDK 14 EA

A nouveau il existe des flags permettant de spécifier l'icone, les métadonnées du lanceur natif (auteur, version, description) et aussi de générer des installeurs ou MSI (sous Windows). Idem lorsqu'on lance ça sur d'autres OS (Linux, macOS) on a des lanceurs et installeurs pour ces OS.

Ici est la bonne étape pour procéder à une signature numérique du lanceur natif EXE d'ailleurs (idem pour les installeurs)

Je tiens d'ailleurs à préciser que tant qu'on ne change pas les modules cores ou FX ou la version de la JVM nécessaires à faire tourner l'application, on a pas du tout du tout besoin de régénérer le lanceur natif, tout ce qu'on a besoin de faire quand on veut générer une nouvelle version de notre application c'est de remplacer le JAR principal et les dépendances qui sont contenus dans le répertoire app de l'image native par de nouvelles versions.

Un immense merci pour vos réponses et tout particulièrement à Bouye qui a pris le temps d'apporter des réponses très complètes.

J'ai vraiment l'impression que Java est en train de foncer droit dans le mur (tout du moins pour la programmation à cible desktop). L'idée de dépouiller le JDK de bibliothèques passées en modules complique la vie des développeurs les plus chevronnés alors ne parlons même pas des newbies... L'expérience utilisateur n'est pas mieux. Quand un simple .jar exécutable suffisait (UI contruite avec JavaFX), il faut désormais passer par une installation (courte mais une installation tout de même).

De plus, il me semble avoir réalisé que tous les IDE ne se valent pas. Personnellement j'utilise Eclipse mais la gestion des modules complémentaires (javaFX et css entre autres) n'est pas évidente (javaFX) ni complètement fonctionnelle (css). Pour pouvoir exporter mon projet j'ai du transiter par NetBeans. Pour le peu que je l'ai utilisé, ça a l'air nettement plus solide. Tout semble bien pris en charge dès le début, pas besoin de galérer à ajouter des extensions. Je verrai si ça se confirme à l'usage car oui, je pense que je vais quitter Eclipse pour NetBeans.

Pour conclure, j'ai finalement réussi à exporter mon projet grâce aux conseils de Bouye.
Dans VirtualBox j'ai créé une machine virtuelle sous Windows 7. J'y ai installé le JDK10 d'Oracle (oh magie ! Java se place tout seul dans le PATH ce qui n'est plus le cas avec le JDK13, merci Oracle !) et NetBeans 8.2. Ensuite j'ai installé InnoSetup que j'ai ajouté au Path.
J'ai importé mon projet dans NetBeans puis dans les propriétés du projet j'ai cliqué sur Build/Deploiement puis sur Enable Native Packaging.
A partir de là j'ai pu faire un clic droit sur mon projet puis Package As -> exe installer.

Et là, miracle, ça fonctionne. Un exe est généré qui est en fait un installer de votre projet. Une fois la courte installation faite, votre projet est utilisable.

J'espère que ce topic sera utile à tous ceux qui, comme moi, ont été désespéré face à l'incapacité d'exporter leur projet.

Il est maintenant temps de creuser toutes les réponses qui ont été apportées car il y en certaines que j'ai du survoler.

Citation:

---

Dans le cadre d'un projet NetBeans JavaFX, la tache de packaging se lance sans erreur... mais aucune idee de l'endroit ou il va stocker les fichiers... (en tout cas pas dans le projet)

---

Bouye, quand tu fais référence à ton essai de jpackager avec NetBeans 11, tu ne sais pas où il stocke les fichiers, c'est à dire ?
Tu as tout de même une installer en .exe qui fonctionne et que tu sais retrouver ?

Citation:

---

Envoyé par Vahia

J'ai vraiment l'impression que Java est en train de foncer droit dans le mur (tout du moins pour la programmation à cible desktop).

---

C'est a peu près mon avis depuis la sortie du JDK 9. Cela a aussi coïncidé avec le fait qu'Oracle a largué NetBeans a Apache (passage de 8.2 a 9) et qu'ils ont mis plus d'un an avant de sortir une nouvelle version. Disons qu'une période d’instabilité des outils internes et tiers a débuté et qu'on a pas encore atteint le pallier de stabilité et de maturité des outils qu'on avait précédemment (et qui datait grosso-modo du JDK 6). Le fait qu'un nouveau JDK sorte tous les 6 mois avec parfois des changements drastiques dans les contenus et les outils embarqués n'aide pas vraiment.

Non je n'ai pas la moindre idée de l'endroit ou NetBeans 11 peut générer les output ni même s'il le fait vraiment* (pourtant les logs de la tache ANT et de javapackager semblent être sans erreur), d’où mon process a mano après (qui est sommes toutes peu différent de ce que j'ai fait ensuite avec jpackage).

*Ou alors il les efface immédiatement après les avoir générés.

De toutes manières avec la sortie sous peu du JDK 14 (et de JavaFX 14) on peut supposer que l'emphase va être portée sur le support de jpackage puisque, en théorie, cet outil est censé rester sur la longueur. Cependant il ne faut pas oublier que GraalVM est au coin de la rue et que ça permettra de créer des applications 100% natives (et non pas un lanceur natif qui appelle la JVM embarquée pour lancer des JAR comme ce qu'on vient de faire) et que donc a un moment ou un autre, il faudra se pencher sur ça.

Désormais que tu as ton lanceur, la gestion des installeur ou des MSI est a ton choix apres :

• tu peux continer a utiliser javapackager/jpackage (qui se reposent sur Wix) - ce que tu as pu faire via NetBeans
• tu peux directement invoquer Wix
• tu peux utiliser un autre outil (moi j'utilise NSIS en général)

Concernant le soucis des CSS sur Eclipse, est-ce que ca pourrais venir au choix de :

• Eclipse ne recopie pas et n’empaquette pas les CSS avec le reste des ressources et le projet lors de la phase de compilation ?
• ou au contraire il les compile en BSS (CSS au format binaire) qui est une option valable pour un projet JavaFX (mais ça oblige a changer les noms des fichiers CSS dans les sources et les FXML) ?

En fait Eclipse interprète correctement le CSS car quand je lance le projet dans l'IDE tout sort parfaitement.
Le truc qui "cloche" c'est que dans les fichiers css, toutes les instructions sont soulignées en jaune pour signaler une erreur. L'impact n'est que visuel au moment de coder mais ce n'est pas super agréable...

Ah ok donc c'est plutôt un soucis visuel lors de l'édition. C'est du niveau des dernières version d'IDEA qui ont refourgué les aides (complétion) et visuels et la coloration syntaxique des CSS dans les versions premium alors qu'avant ça marchait très bien dans les versions gratuites :mouarf:

Digression 2 :

Suite à la lecture de ce thread, et également aux soucis que tout le monde semble avoir. Un tuto (de préférence plateforme agnostique) a t’il été réalisé quelque part pour avoir "rapidement" un projet jfx préférablement a base de openjdk/jre/jfx. Projet qui soit multi-plateforme et multi-architecture.

Je ne crois pas l’avoir vu il existe :
- https://adoptopenjdk.net/

Je rejoins les avis exprimés plus bas sur le fait que java va dans le mur. Sans doute en voulant aller trop vite. Ils ont completement oubliés que des gens travail avec java. C’est assez impressionnant je trouve et pas du tout professionnel.

Pour finir merci a bouye