Discussion :

[kirua29]

Bonjour,

J'aurais une petite question à propos de la modification d'UI depuis un thread secondaire.

A ma connaissance en C#/VB.Net et en Java Android il est interdit de faire des appels cross thread pour modifier l'UI d'une application et donc il faut faire un invoke pour modifier depuis le thread principal.
Mais j'ai un doute pour ce qui est du Java "normal" pour application bureau. Est-il autorisé de modifier directement l'UI depuis un thread secondaire ? (Pour une application simple avec le thread principal et un thread secondaire.)

Merci.

Cordialement.

[adiGuba]

Salut,


Par Java "normal" tu veux parler de Swing/AWT ?
Et bien c'est la même chose : il faut passer par le thread de l'UI pour la modifier.

Généralement çà passe par la méthode SwingUtilities.invokeLater() ou des classe qui intègre cela (comme SwingWorker).


a++

[kirua29]

Ouep Je parles de Java Swing/AWT. D'un thread (New Thread() donc) qui modifierait l'UI de mon application (déplacer un bouton dans une JFrame).

D'accord !
J'avais un doute car aujourd'hui un de mes profs me soutenait dur comme fer que n'importe quelle thread pouvait modifier l'UI alors qu'on m'avait toujours dit que non.

Merci pour ta réponse !

[joel.drigo]

En JFace/SWT, par exemple, tu obtiendras imanquablement une exception indiquant que le thread faisant l'invocation n'a pas le droit d'invoquer la méthode de classe de l'API SWT.
En Swing/AWT, même s'il ne faut pas le faire, tu pôurras le faire sans ce type d'exception directe, mais c'est un gros risque de dysfonctionnements, allant des défauts purement graphiques, jusqu'aux exceptions pour accès concurrents, en passant par une interface pas forcément à jour.

[kirua29]

Merci pour ces précisions !

[adiGuba]

J'avais un doute car aujourd'hui un de mes profs me soutenait dur comme fer que n'importe quelle thread pouvait modifier l'UI alors qu'on m'avait toujours dit que non.

Tu pourras dire à ton prof qu'il a tord, et c'est même indiqué sur toutes les pages de javadoc des composants Swing :

Code :

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

 Warning: Swing is not thread safe. For more information see <a href="https://docs.oracle.com/javase/7/docs/api/javax/swing/package-summary.html#threading" target="_blank">Swing's Threading Policy</a>.

La plupart des modifications de l'interface doivent se faire dans le thread de l'UI (plus précisément l'EDT - Event Dispatch Thread), qui est créé automatiquement lorsque tu affiches ta première fenêtre (ou que tu utilises invokeLater()).
Il existe bien quelques rares méthodes thread-safe utilisable depuis n'importe quel thread... mais il faut consulter la doc pour chaque méthode pour le savoir.

Plus d'info ici : https://docs.oracle.com/javase/tutor.../dispatch.html


Après comme le dit joel.drigo, la principale différence avec d'autres librairies graphiques c'est que cela ne provoquera pas une erreur immédiatement.
Mais du coup c'est pire car cela peut marcher... ou décaler l'erreur et donner des comportements imprévisibles et aléatoire.



Donc pour ton besoin (un thread qui déplace un bouton), il faut utiliser soit un Thread+invokeLater(), soit un SwingWorker qui intègre et facilite un peu tout çà.


a++

[bouye]

AWT/Swing : SwingUtilities.invokeLater()
JavaFX : Platform.runLater()

Pendant TRÈS longtemps les exemples du JDK, les didacticiels et même les bouquins experts de Sun faisaient cette erreur grossière dans leurs cours sur AWT et Swing et donc ces mauvaises pratiques de modifier l'UI depuis le thread tiers se sont perpétuées dans toute une génération de développeurs / enseignants / étudiants. De plus, il a fallu attendre Java 5 pour voir apparaitre SwingWorker (dispo auparavant en lib tiers si mes souvenirs défaillants sont corrects) ce qui a permis enfin aux développeur de ne plus avoir besoin de gérer manuellement leur thread tiers pour les taches de fond.

En JavaFX, il est possible (mais pas 100% du temps donc il faut faire attention) de faire des modifications hors du thread évènementiels tant que le nœud n'est pas attaché a une scène. A partir du moment ou il est attaché a une scene (et donc potentiellement affichable), ça lèvera une exception la majorité du temps. Donc la bonne pratique c'est d'utiliser runLater(). La lib inclue d'office le couple Service/Task pour gérer les taches de fond.

[adiGuba]

De plus, il a fallu attendre Java 5 pour voir apparaitre SwingWorker (dispo auparavant en lib tiers si mes souvenirs défaillants sont corrects)

C'était pire que çà : il fallait récupérer le code source dans un des tutoriels de Sun...



Pour moi le plus gros problème d'AWT/Swing c'est que la modif hors-EDT ne produise pas systématiquement une exception.
Du coup on se prend tout les problèmes lié à l'absence de synchro multithread : des fois çà semble marcher, et des fois non.
Pire : cela peut générer des erreurs incompréhensible "plus tard"...