[Java] Problèmes de XInitThreads (Abandonné)

Ce qui ne concerne ni le forum ni des problèmes
Répondre
Avatar de l’utilisateur
Dakyne
Daikyu
Messages : 52
Inscription : mer. 01 juin 2016, 15:12
Localisation : France
Contact :

[Java] Problèmes de XInitThreads (Abandonné)

Message par Dakyne » jeu. 25 mai 2017, 18:27

Bonjour,

Je suis depuis récemment sous arch, et j'ai un projet pour mon iut (un bomberman en lan, en java avec jsfml). Tout allait bien sous windows, mais sous linux, j'arrive pas à lancer mon programme correctement (si je spamme un peu le bouton « run » ça marche dès fois).
L'erreur qui m'est renvoyée :

Code : Tout sélectionner

/usr/lib/jvm/java-8-jdk/bin/java -javaagent:/usr/share/intellij-idea-ultimate-edition/lib/idea_rt.jar=37443:/usr/share/intellij-idea-ultimate-edition/bin -Dfile.encoding=UTF-8 -classpath /usr/lib/jvm/java-8-jdk/lib/ant-javafx.jar:/usr/lib/jvm/java-8-jdk/lib/dt.jar:/usr/lib/jvm/java-8-jdk/lib/javafx-mx.jar:/usr/lib/jvm/java-8-jdk/lib/jconsole.jar:/usr/lib/jvm/java-8-jdk/lib/packager.jar:/usr/lib/jvm/java-8-jdk/lib/sa-jdi.jar:/usr/lib/jvm/java-8-jdk/lib/tools.jar:/home/merguez/Documents/Dev/Bomber/out/production/Bomber:/home/merguez/Documents/Dev/jsfml/jsfml.jar BomberLAN.GameBoard
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
java: xcb_io.c :165 : dequeue_pending_request:  l'assertion « !xcb_xlib_unknown_req_in_deq » a échoué.

Process finished with exit code 134 (interrupted by signal 6: SIGABRT)
J'ai remarqué que c'est une erreur courante en C mais j'ai rien trouvé de bien concret pour le java.

J'ai essayé avec le jdk officiel et l'openjdk.

Merci bien !

(Je suis pas sûr d'être dans la catégorie adaptée…)
Dernière édition par Dakyne le jeu. 25 mai 2017, 21:05, édité 1 fois.
Arch, Awesome, Zsh, BÉPO - i5 6600K@4.2GHz, GTX970, 16Gio DDR4 :chinois:

Avatar de l’utilisateur
benjarobin
Maître du Kyudo
Messages : 15160
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [Java] Problèmes de XInitThreads (Facepalming)

Message par benjarobin » jeu. 25 mai 2017, 18:44

Bonjour,
Il y a une erreur de conception dans le programme Java. Tu n'as le droit d’interagir avec l'interface graphique que depuis le thread principal. Il est interdit de modifier des éléments graphiques depuis d'autres threads
Après sans le code, difficile d'en dire plus
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Avatar de l’utilisateur
Dakyne
Daikyu
Messages : 52
Inscription : mer. 01 juin 2016, 15:12
Localisation : France
Contact :

Re: [Java] Problèmes de XInitThreads (Facepalming)

Message par Dakyne » jeu. 25 mai 2017, 19:12

C'est fort probable, nous ne sommes pas des codeurs (pour l'instant probablement pour certains). Si tu n'as pas envie ou pas la foi, ne te prend pas la tête !
Le code : https://github.com/Dakyne/BomberLAN
Merci en tout cas
Arch, Awesome, Zsh, BÉPO - i5 6600K@4.2GHz, GTX970, 16Gio DDR4 :chinois:

Avatar de l’utilisateur
benjarobin
Maître du Kyudo
Messages : 15160
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [Java] Problèmes de XInitThreads (Facepalming)

Message par benjarobin » jeu. 25 mai 2017, 19:42

C'est fort possible que cela ne vienne pas de votre code, mais de jsfml. Pourquoi vous vous êtes basé sur un projet mort / abandonné (jsfml), dont il n'y a plus de site et aucune version stable ? Je crains qu'il n'y ai pas de vrai solution à part tout refaire avec des technologie plus récente. Un conseil abandonner Java et faites le en Qt :-) Après cela demande d'autres compétences
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Avatar de l’utilisateur
Dakyne
Daikyu
Messages : 52
Inscription : mer. 01 juin 2016, 15:12
Localisation : France
Contact :

Re: [Java] Problèmes de XInitThreads (Facepalming)

Message par Dakyne » jeu. 25 mai 2017, 19:54

On était partis sur C++ et sfml (que je maîtrise mieux !) mais notre prof nous a dit de le faire dans un truc qu'on avait déjà vu à l'iut :/ Donc on a pas le choix du langage. Je vais regarder ce que c'est Qt par curiosité quand même :p
D'après toi, j'ai pas de solution sans laisser tomber java ?
Arch, Awesome, Zsh, BÉPO - i5 6600K@4.2GHz, GTX970, 16Gio DDR4 :chinois:

Avatar de l’utilisateur
benjarobin
Maître du Kyudo
Messages : 15160
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [Java] Problèmes de XInitThreads (Facepalming)

Message par benjarobin » jeu. 25 mai 2017, 20:48

Il y a sans aucun doute d'autres solution sans laisser tomber java, mais avec sfml plus dur...
Je ne sais vraiment pas trop quoi te dire...
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Avatar de l’utilisateur
Dakyne
Daikyu
Messages : 52
Inscription : mer. 01 juin 2016, 15:12
Localisation : France
Contact :

Re: [Java] Problèmes de XInitThreads (Facepalming)

Message par Dakyne » jeu. 25 mai 2017, 21:04

Bon j'aurais tenté au moins :p je vais devoir continuer sous windows :(
Merci quand même !
Arch, Awesome, Zsh, BÉPO - i5 6600K@4.2GHz, GTX970, 16Gio DDR4 :chinois:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10400
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [Java] Problèmes de XInitThreads (Facepalming)

Message par FoolEcho » ven. 26 mai 2017, 10:10

benjarobin a écrit :
jeu. 25 mai 2017, 18:44
Il y a une erreur de conception dans le programme Java. Tu n'as le droit d’interagir avec l'interface graphique que depuis le thread principal. Il est interdit de modifier des éléments graphiques depuis d'autres threads
Pas exactement. Ton thread principal est censé en lancer un autre dédié au graphique et tout se passe dans ce dernier... en théorie.
Dakyne a écrit :
jeu. 25 mai 2017, 19:54
D'après toi, j'ai pas de solution sans laisser tomber java ?
Tout dépend des spécifications, de ce qu'on souhaite obtenir (client/serveur léger ou lourd ? applet ? application ?), de ce que tu as à disposition (tu as un squelette, des impératifs ou tu pars de zéro ?)...
Techniquement tout peut être fait en pur swing, voire java2D, je ne pense pas qu'aller plus loin présente de l'intérêt (le fond du programme ne pose pas de problèmes en soi, au delà de la conception, voir plus bas ; sur le fond par contre java n'est pas vraiment adapté à faire du jeu même s'il existe des contre-exemples et que pas mal d'API existent: on se tourne vers du C++/Qt en effet, ne serait-ce que pour des questions de performance).

Un petit condensé de ce qu'il est possible d'utiliser:
https://openclassrooms.com/forum/sujet/ ... java-18410

Je ne vais pas m'étendre sur le sujet, mais pour avoir parcouru votre code rapidement, j'ai souri... :mrgreen:
Sur le fond, un Indice pour développer différemment: ce n'est pas parce que le terrain de jeu est un espace en deux dimensions (ou plus) qu'il est nécessaire d'avoir une représentation en mémoire de chaque case à tout instant (en gros: tu n'as pas besoin d'une matrice, à plus forte raison car ce type d'objets est lourd et peu performant... ce ne sont pas les moyens de gérer des listes ou des collections qui manquent en java: facilité d'accès, de manipulation, d'opérations). Et pousser l'analyse plus loin (quid de mon projet actuel si je dois passer à 3 dimensions... je peux te garantir qu'en l'état tu vas souffrir :copain: ). Pas évident à réaliser d'entrée puisqu'il y a l'influence du résultat graphique justement.
Mais pour bien concevoir ton projet, il faut dissocier l'interface graphique («trivial» à réaliser) du cœur du fonctionnement. En gros, «comment je fais fonctionner mon joujou sans une once de graphique ? » «et si je veux tout changer graphiquement ? » etc. (idéal pour tester pas à pas : une fois le fonctionnement garanti, le graphique n'est plus «que» de l'habillage ) Y a une tentative de ça sur ce que je vois, faut juste la pousser un peu plus loin...

Mais au delà de ça (l'analyse et la conception demandent de la réflexion, du temps et de l'expérience... on te demande forcément de produire quelque chose mais rien ne t'empêche de dire également ce qui te chagrine, ce que tu aurais voulu pousser plus loin, etc..), surtout une chose essentielle: commenter et nettoyer votre code, c'est impératif. :chinois:
«The following statement is not true. The previous statement is true.» :nage:

Avatar de l’utilisateur
Dakyne
Daikyu
Messages : 52
Inscription : mer. 01 juin 2016, 15:12
Localisation : France
Contact :

Re: [Java] Problèmes de XInitThreads (Abandonné)

Message par Dakyne » ven. 26 mai 2017, 14:47

FoolEcho a écrit :
ven. 26 mai 2017, 10:10
Tout dépend des spécifications, de ce qu'on souhaite obtenir (client/serveur léger ou lourd ? applet ? application ?), de ce que tu as à disposition (tu as un squelette, des impératifs ou tu pars de zéro ?)...
Je connais pas précisément les différences, mais j'ai l'intention d'avoir un exécutable java et un serveur java. Donc un client qui affiche et un serveur qui calcule :p

Merci en tout cas !
Arch, Awesome, Zsh, BÉPO - i5 6600K@4.2GHz, GTX970, 16Gio DDR4 :chinois:

Avatar de l’utilisateur
FoolEcho
Maître du Kyudo
Messages : 10400
Inscription : dim. 15 août 2010, 11:48
Localisation : Basse-Normandie

Re: [Java] Problèmes de XInitThreads (Abandonné)

Message par FoolEcho » sam. 27 mai 2017, 09:14

Dakyne a écrit :
ven. 26 mai 2017, 14:47
Je connais pas précisément les différences, mais j'ai l'intention d'avoir un exécutable java et un serveur java. Donc un client qui affiche et un serveur qui calcule :p
Nan. Client-serveur c'est typiquement dans l'optique d'un développement réseau (le client génère des requêtes que traite le serveur => plus largement, l'ensemble des données est partagé entre tous les clients).
Ici tu es dans le cadre d'un patron de conception parmi les plus courants: MVC. Modèle (la représentation de tes données de jeu) - Vue (l'affichage) - Contrôleur (les règles de jeu et les interactions utilisateurs). Si tu t'appuies là dessus, tu pourras organiser ton développement au mieux (un patron de conception est une réponse à un type de problème donné ; même si on peut toujours les adapter ou les combiner, comme c'est le cas du MVC, ils fournissent une base de travail propre à des problèmes de conceptions classiques ... ainsi, tu ne réinventes pas la roue).
«The following statement is not true. The previous statement is true.» :nage:

Répondre