Discussion :

[WipEout37]

Bonjour à tous,

Mon programme fonctionne sous eclipse. Mais en lançant le jar correspondant, j'obtiens l'erreur suivante :

Code Console :

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
C:\Users\jso36>java -jar DT.jar
Graphics Device initialization failed for :  d3d, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: 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:243)
        at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260)
        at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
        at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
        at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
        at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
        at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
        at java.base/java.lang.Thread.run(Thread.java:835)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
        at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
        at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
        ... 1 more
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:567)
        at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:61)
Caused by: java.lang.RuntimeException: No toolkit found
        at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272)
        at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
        at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
        at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
        at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
        at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
        at java.base/java.lang.Thread.run(Thread.java:835)
 
C:\Users\jso36>

J'utilise Java FX.A priori cela a un rapport.
En vous remerciant ….

[bouye]

Quelle version de Java utilises-tu ? JavaFX ne fait plus partie du JDK depuis le JDK 11 et doit donc être fourni avec les JAR. Tu dois donc t'arranger via jlink, maven ou graddle pour créer une distribution, un ensemble de fichier qui fourni tout ce dont ton app a besoin pour fonctionner (sachant qu'en plus javapackager n'est plus dispo egalement et que jpackager ne sera pas dispo avant au moins le JDK 13).

[WipEout37]

Salut,

J'utilise le javafx 12. J'ai bien intégrer les jar de java fx dans le jar. Cf l'image ci-dessous pour voir l'option que j'ai sélectionnée. Merci d'avance.

[bouye]

Ah du coup c'est de l'Eclipse donc jamais utilisé ce plugin ni ne sait comment faire... Il manque peut-être la partie native de JavaFX qui est propre à chaque plateforme. Il va falloir peut-être se renseigner sur StackOverflow ou sur un forum Eclipse ou tournant autour de ce plugin.

[WipEout37]

J’ai trouvé quelquechose sur Staroverflow mais il faut rajouter des fichiers à la main (genre des dll) mais je ne connais pas de site sûr pour télécharger ces dll.

Sinon cela pose la question de la portabilité du programme : comment installer ce programme facilement sur un autre pc ... ça commence à être une usine à gaz.

[WipEout37]

Voila le topic en question :

https://stackoverflow.com/questions/...ntimeexception

si tu as un avis je suis preneur.

[bouye]

Je regarderai demain mais en théorie les DLLs devraient être dans les binaires publiés par Gluon. Après c'est jamais forcément super facile de faire un package complet pour un programme ; le but c'est que ça soit facile à installer par l'utilisateur, ça veut pas forcément dire que ça sera facile à faire pour le programmeur.

[joel.drigo]

Salut,

Oui, intégrer des librairies natives dans un jar, c'est pas terrible... il faut en faire pour chaque os, ça risque de poser des problèmes de compatibilité de versions, d'alourdir le jar aussi, inutilement si le sdk est déjà installé, etc..

Je n'ai regardé qu'en diagonale, mais y'a ça qui a l'air pas mal : https://github.com/edvin/fxlauncher

[bouye]

Ne nous voilons pas la face, cela fait plusieurs années que distribuer un jar est vu comme une mauvaise pratique. Sans parler du fait que plein d'utilitaires de compression/archives s'emparent du format ce qui empêche de le lancer, on a aussi le problème de vérification de la signature par l'utilisateur final lambda ( gné) puisqu'il faut passer par Java pour cela. Et le pire bien sur devoir se reposer sur une JVM système qui sera pas forcement a jour, ou a la version qu'on souhaite, ou même pas présente du tout (ce qui est le plus courant de nos jours), etc.

Donc, non, la bonne pratique désormais, c'est les JVM embarquées, les installeurs et les lanceurs natifs avec les signatures qui vont bien pour que et l'OS et l'anti-virus se chargent des vérifs comme n'importe quelle app native, donc du Java bien mieux intégré que par le passé. Encore plus bien sur si on décide de passer par les stores officiels des OS (ou on a pas le choix). Donc que qu'il y ait du natif c'est pas un soucis en soit puisque de toutes manières il faudra produire un package pour Windows, un autre pour macOS, etc.

PS : et c'est une remarque valable pour n'importe quoi d’écrit en Java -ex une app Swing-, pas juste pour JavaFX.

Encore faut-il que les outils pour le faire soient corrects mais comme mentionné plus haut hélas, en l'absence de javapackager mis de coté depuis le JDK 9 et carrément absent depuis le 11 et comme jpackager est toujours en phase bêta avec peu de doc ou d'outils, force est de constater qu'on est en phase de régression par rapport aux capacités du JDK 8 ; jlink se contentant de produire un bon gros vieux fichier bat des familles, ne supportant pas les app non-modulaires ou encore étant sacrément obscur et pas forcement bien documenté ni avec des plugins ou outils matures (je cherche encore ou vont les fichiers de mon app et de mes lib dans une image jlink ou même comment lui faire embarquer les jmods de JavaFX justement ou ou il a bien pu mettre les références vers les chemins sur les libs JavaFX que j'ai déclarées dans mon projet NetBeans... et ne parlons pas du support inexistant dans IDEA*...)...

*D'ailleurs l'artefact JavaFX application (fx:deploy) présent dans les versions d'IDEA actuelles repose sur javapackager et donc ne fonctionne plus des qu'on a le JDK 11.

FXLauncher semble sympa sur le papier, bref c'est un peu comme Java Web Start en théorie (sauf que ce dernier n'a jamais fonctionné correctement pour moi). A voir ce que ça donne a travers d'un réseau qui ne sera pas plombé par des sécurités demandant des authentifications spécifiques donc ça peut être bien pour certains types de solutions mais ce n'est pas non plus une solution miracle universelle. La doc de FXLauncher indique qu'il peut fonctionner en collaboration avec un lanceur natif comme ceux créés par javapackager ou d'autres lanceurs natifs pour Java. Pour ce que j'en comprends par contre il faut quand même fournir les libs et les whatnot, c'est pas FXLauncher qui va s'en charger. J'ai rapidement testé sur un petite projet local sans arriver a lancer quoi que ce soit donc pour le moment mon avis reste réservé quant a cette solution.

PS: la partie native de JavaFX ce sont bien tous les DLLs (resp les libs pour les autres OS) qui sont presents dans le repertoire bin du SDK fourni par Gluon. Lorsqu'on utilise les fichiers jmod avec jlink (note de moi : comment ????) cette partie native est sensee etre directement incluse dans les fichiers modulaires.