Discussion :

[bouye]

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

[Vahia]

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.

[Vahia]

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 ?

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

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 ?

[joel.drigo]

Salut,

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 ?

[bouye]

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)

[bouye]

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 :

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

  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 text :

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

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

test/styles.css

Code CSS :

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

1
2
3
4
5
6
.root {
}
.vbox {
    -fx-alignment: center;
    -fx-spacing: 10px;
}

test/test.fxml

Code XML :

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

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 :

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

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 :

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

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 txt :

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

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

[Vahia]

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

[Vahia]

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 :

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

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 :

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

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

[bouye]

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.

[bouye]

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

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 :

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

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.



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.



META-INF/MANIFEST.MF

Code text :

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

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.


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 console :

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

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


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.

[Vahia]

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.

[Vahia]

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 ?

[bouye]

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)

[bouye]

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

[Vahia]

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

[bouye]

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

[Bardotj]

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