Thread vs SwingWorker

Bonjour,

je viens de découvrir l'existence de SwingWorker, et je me demandais ce que ça apportait de plus qu'un simple Thread...

J'ai un peu googeulisé le truc, et apparemment, SwingWorker serait utilisé quand on veut modifier des éléments d'une GUI, et autrement on prendrait un Thread classique...

Sauf que personnellement j'ai toujours mis à jour mes GUI avec des Thread, et ça ne m'a jamais posé de problème jusqu'à maintenant !

Je viens encore à l'instant de faire une JProgressBar mise à jour depuis un Thread, lancé lui même depuis un click sur un JButton, et elle marche nickel (pourtant le Thread est très lourd, il rend la main à swing en faisant des appels à yield() de temps en temps dans la boucle de traitement)

Donc ma question est simple, que pourrait m'apporter de plus cette classe SwingWorker ? (si ce n'est m'embrouiller la tête avec de nouvelles méthodes alors ma fonction run() me convenait)

Merci !

PS : J'me rend compte que le sujet à déjà du être abordé 20 fois, mais comme j'ai pas écris ça pour rien, je le poste quand même :)

le swingworker présente quelques facilités:

la notion de propriétés et de propertychangelistener, qui permet d'ajouter des listener, par exemple sur la progression de la tâche
l'appel d'une méthode done() en fin de travail (permet de faire des trucs spécifiques à la fin du boulot)
une méthode progress qui est garantie d'etre appelée au sein de l'event dispatch thread (ce qui permet de manipuler les composant swing)

Pour info, bien souvent on manipule allègrement les composant swing depuis n'importe quel thread. Masi ces composants ne sont pas thread-safe et devraient, normalement, n'être accéder que depuis le Thread AWT. Swingworker gère çà.

Si je ne dis pas de bêtises, les composants Swing (sauf certains et c'est spécifié dans la doc), ne sont pas thread safe.
Ils doivent dont être "manipulés" dans l'EDT, le thread responsable des traitements liés à l'interface graphique.
Si tu ne le fais pas, tu peux avoir des problèmes.
Il vaut donc mieux le faire, ça t'éviterait un jour de tomber sur des bugs bizarres.

ok, donc en gros dans les 3/4 des usages basiques un thread pourrait faire l'affaire, mais dans le cas de grosses usines à gaz où les threads se multiplient et touchent aux mêmes objets graphiques (genre la GUI d'eclipse ou de netbeans, pas mon truc à 3 JButtons qui se battent en duel !) il faut mieux faire ça proprement avec SwingWorker.

Pour finir les bonnes pratiques recommandent de faire du SwingWorker tout le temps même avec des Threads simples dès lors qu'on touche à swing, comme ça pas de mauvaises surprises.


Bon... Ca m'embête, j'm'étais bien habitué à mes threads...

Je vais donc devoir faire de l'auto-persuasion pour me faire écrire doInBackground() plutôt que run() :)

Citation:

---

Envoyé par cho7

ok, donc en gros dans les 3/4 des usages basiques un thread pourrait faire l'affaire, mais dans le cas de grosses usines à gaz où les threads se multiplient et touchent aux mêmes objets graphiques il faut mieux faire ça proprement avec SwingWorker.

---

Non, même avec un seul Thread, même si c'est rare, tu pourrais avoir des problème. N'oublie pas que les gestion de bases d'évènement font aussi des modifs sur les composants. Exemple, tu réagit à un redimensionnement de fenetre en redessinant une ilmage, tu manipule le JPanel contenant l'image dans un Thread à part, mais swing va aussi manipuler ce JPanel pour le redimensionner.

Si tu ne veux pas utiliser SwingWorker, tu peux.
Dans ce cas là, dans les threads où tu as besoin de toucher à l'interface, place ces modifs dans un runnable que tu passes à la méthode invokeLater.
C'est juste que SwingWorker masque tout ça et au final c'est plus simple.

Citation:

---

Envoyé par tchize_

Non, même avec un seul Thread, même si c'est rare, tu pourrais avoir des problème. N'oublie pas que les gestion de bases d'évènement font aussi des modifs sur les composants. Exemple, tu réagit à un redimensionnement de fenetre en redessinant une ilmage, tu manipule le JPanel contenant l'image dans un Thread à part, mais swing va aussi manipuler ce JPanel pour le redimensionner.

---

Hum, vu sous cet angle... Bon, promis j'essais de mettre du SwingWorker dans mes prochaines applis :)

Merci pour l'éclaircissement !

Salut,



Tu peux tout à fait utiliser un thread, mais dans ce cas tu devras utiliser SwingUtilities.invokeLater() lorsque tu veux mettre à jour la GUI. Sinon tu risques de te retrouver avec des erreurs aléatoires selon les exécutions.

Le fait que tu utilises des yield() me laisse craindre le pire : ce ne serait pas une rustine permettant de cacher ces erreurs aléatoires ???


SwingWorker permet de faire un cadre de travail pour ce genre de tâche :

• doInBackground() te permet d'exécuter les actions "lourdes" dans une tâche de fond, sans que cela ne bloque l'interface graphique.
  
• done() (optionel) te permet de mettre à jours l'affichage à la fin du traitement.
  
• process() (optionel) te permet de mettre à jours des données intermédiaire récu pendant le traitement via publish()
  
• Enfin setProgress() te permet de mettre à jour une ProgressBar via un PropertyListener. Le seul défaut c'est qu'à ma connaissance il n'y ait rien de tout fait dans l'API standard, mais ce n'est pas la mort à coder pour que les modifications du SwingWorker soit répercuté sur une progressbar :
  
  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

  class ProgressBarListener implements PropertyChangeListener {   private final JProgressBar progressBar;   public ProgressBarListener(JProgressBar progressBar) { this.progressBar = progressBar; }   @Override public void propertyChange(PropertyChangeEvent evt) { // En cas de changement de la valeur de progression if ("progress".equals(evt.getPropertyName())) { // On change directement la valeur de la ProgressBar this.progressBar.setValue(((Integer)evt.getNewValue()).intValue()); } else if ("state".equals(evt.getPropertyName())) { // En cas de changement de l'état du SwingWorker : SwingWorker.StateValue state = (SwingWorker.StateValue) evt.getNewValue(); switch(state) { case PENDING: // En attente de démarrage case STARTED: // Démarrage du SwingWorker // On initialise la progressBar au minimum this.progressBar.setValue(this.progressBar.getMinimum()); break; case DONE: // SwingWorker terminé : // On met au maximum this.progressBar.setValue(this.progressBar.getMaximum()); break; } } } }

  ---

Je pense que le mieux serait de prendre un cas concret, et de le faire avec les deux méthodes pour vori ce que ca donne comme différence ;)


a++

Je reposte ici car en testant un ptit chat udp que j'ai développé à la va vite, mes collègues avaient des freezes par moment, ce qui vautrait l'application et les obliger à tuer le processus javaw.exe

Du coup, j'ai mis mes 2 fonctions setText() (une qui affichait les messages entrants dans un jtextarea, et une qui remettait à blanc la zone de saisie de message une fois le message envoyé) dans un invokeLater, et depuis tout roule beaucoup mieux.

Donc effectivement, les threads qui touchent à swing directement, selon les ordinateurs et le temps qu'il fait, c'est tout blanc ou tout noir.

Parcontre pour l'utilisation que j'en fais, le invokeLater me parait syntaxiquement plus simple à utiliser que le SwingWorker...

Bonjour,

je m'intéresse au problème car j'ai également l'habitude de rafraîchir mon interface graphique à la fin du Thread de calcul.

Je peux comprendre que si j'envoie beaucoup d'informations complexes de rafraîchissement d'images à mon interface graphique et que l'EDT veut y retoucher dans le même temps, ça risque de poser des problèmes. Mais imaginons que je reste sur un schéma simple : j'appuie sur un bouton, je lance un thread qui fait un calcul et à la fin du calcul, dans le thread, j'appelle setText() sur un label. L'opération sur l'IHM me paraît de relativement courte durée. Ai-je un réel risque sur ce type de procédé ou est-ce anecdotique ? Concrètement, qu'est ce qu'il risque de m'arriver ?

J'ai peur que l'utilisation de SwingUtilities rende mon code moins lisible et plus difficilement entretenable. Est-ce que j'encours un risque suffisant pour "dégrader" cette lisibilité ?

Oui, toute personne connaissant swing sait à quoi sert l'appel à invokeLater, et dans ce cas le code en est d'autant plus lisible.
De plus, du fait de l'architecture de Swing qui ne peut t'assurer qu'un composant sera en état de subir une modification que si tu poste la demande de modification dans l'EventQueue. L'action de poster une demande dans l'EventQueue étant réalisée par l'appel à invokeLater si l'on se trouve en dehors de l'EDT, ou si l'on se trouve déjà dans l'EDT il suffit juste d'appeler la méthode.

A savoir que c'est également la manière de procéder dans SWT qui est de fait beaucoup moins tolérant de ce coté là. En effet tout instruction sur un composant graphique ne provenant du thread graphique lance une exception.

Donc cette manière de coder est commune au niveau des interfaces graphique, et de ce fait aisément reconnue, donc pas considérée comme alourdissant le code source (surtout si lon structure correctement celui ci).

Bon ensuite la classe SwingWorker permet de designer d'une façon largement plus propre on est d'accord.

Swing est "relativement" tolérant à cet égard. Mais le resultat reste aléatoire, ca marche dans 99% des cas, mais de temps en temps t'aura des users qui te diront que "aléatoirement" les composants de l'interface se déplacent (par exemple...) et le problème sera d'autant plus dur à localiser qu'il sera aléatoire.

De plus, si tu prend par la suite des look and feel différents pour ton application, certains sont beaucoup, beaucoup moins tolérant vis à vis de ça!

Mettre à jour des composants en dehors du thread swing est une erreur courant et d'autant plus sournoise que "ca a l'air de marcher"

Citation:

---

Envoyé par cho7

Sauf que personnellement j'ai toujours mis à jour mes GUI avec des Thread, et ça ne m'a jamais posé de problème jusqu'à maintenant !

---

Citation:

---

Envoyé par fr1man

Il vaut donc mieux le faire, ça t'éviterait un jour de tomber sur des bugs bizarres.

---

Citation:

---

Envoyé par tchize_

Non, même avec un seul Thread, même si c'est rare, tu pourrais avoir des problème.

---

Yep et c'est en parti la faute de Sun car jusqu'aux alentours de 2002~2003 ils n'ont jamais vraiment insiste sur ce fait et pas mal de leurs exemples et didacticiels anterieurs, certains aussi vieux que l'AWT elle-meme, presentent ces defauts. De meme on trouvera nombre de livres faits par des auteurs et maisons d'editions tres respectables qui passent allegrement sur la chose.

La regle a retenir avec les acces directs venant d'une autre Thread c'est : ce n'est pas parce que ca fonctionne la, maintenant, tout de suite sur ton ordi, sur cet OS et avec cette JVM, que cela fonctionnera forcement sur un autre ordi, un autre OS et une autre JVM (differente version, different vendeur). Donc il faut revenir aux methodes conseillees/indiquees.

Je pressent quelques problemes similaires dans JavaFX : aucun des didacticiels et tres peu de presentations actuelles parlent du modele de threading et des interraction entre la thread de JavaFX (si jamais il y en a une), celle de l'interpreteur (dans le cas ou on veut faire du JavaFX interprete au lieu de compile), l'EDT quand on manipule directement les wrappers fournis ou quand on se fait ses propres SwingComponent, les divers threads des TimeLine (a moins qu'il n'y en ait qu'une seule partagee par toutes les TimeLine comme le suggerait une presentation du dernier JavaOne) et les threads annexes qu'on peut etre ammenees a creer pour manipuler entre autre sockets, longs chargements et acces aux BD... Sans parler des propagations des valeurs quand on fait du binding ou du trigger replace...