Swing Event Dispatching Thread

hello :)

Je développe en ce moment une application java desktop : Swing + Spring.

J'ai lu quelques articles et tutoriels et il semble que toute création de composant swing, enfin tout ce qui est lié a swing doit être réalisé au sein d'un thread bien précis : l'Event Dispatching Thread. Pour faire cela, il faut créer un objet type Runnable qui dans sa méthode run() contient notre code swing (création d'une JFrame, ...).
Ensuite donner cet objet Runnable en paramètre à la méthode invokeLater de la classe SwingUtilities. Cela place donc notre requete pour une nouvelle JFrame dans l'EventQueue.
Tout ceci permet d'éviter des problèmes de concurrence entre Thread étant donné que les composant de Swing ne sont pas thread safe.

Est-ce que j'ai bien compris ?

Si oui, le projet Spring RCP, qui vient de connaitre une nouvelle release, instantie des JFrame (par exemple le SplashScreen) directement dans le container Spring et ne respecte donc pas la règle de l'EDT ?

Quelqu'un peut-il m'éclairer ?8O

Ce qui doit être fait dans l'EDT c'est ce qui est dessin des fenêtres, affichage, modifications.
Tu peux très bien instancier une JFrame dans un autre thread, par contre le setVisible(true) devra être appelé dans l'EDT.

Eh bien je n'en suis pas certain !
Selon le livre "Filthy Rich Clients" de Chet Haase et Romain Guy, même la création d'un composant Swing doit se faire au sein de l'EDT !

Citation:

---

Because the JFrame is a Swing component, and because it instantiates another Swing component, it should be created on the EDT, not on the main thread.

---

du livre "Filthy Rich Clients" de Chet Haase et Romain Guy

Citation:

---

Envoyé par YeFFreY

Eh bien je n'en suis pas certain !
Selon le livre "Filthy Rich Clients" de Chet Haase et Romain Guy, même la création d'un composant Swing doit se faire au sein de l'EDT !

du livre "Filthy Rich Clients" de Chet Haase et Romain Guy

---

Bizarre, je ne comprends pas pourquoi ils devraient être instanciés dans l'EDT, ce n'est qu'une création d'objet, il n'y a aucun événement particulier qui arrive dans le cadre d'un comportement standard tant que la fenêtre n'est pas affichée à l'écran.

Il y a peut-être quelque chose que je n'ai pas compris.

ou alors c'est moi qui comprend pas :D

Même si, comme natha, je ne vois pas ce que ça change tant que la frame n'est pas visible, je me suis rangé du coté des recommandations de Sun et j'ai modifié toutes mes interfaces pour qu'elles soient écrites comme il le préconise.
Même si ça ne fait pas de bien, ça ne peut pas faire de mal :haha:

http://java.sun.com/docs/books/tutor...y/initial.html

Fred

Oui alors pour être plus précis, le cas décris ici est le fait de ne pas créer la première frame sur le main thread, mais sur l'EDT. Là ok, c'est clair que c'est mieux comme ça.
Par contre rien n'empêche ensuite de créer tes frames et composants dans d'autres threads lorsque celà s'avère nécessaire car leur création prend du temps.
J'ai des écrans qui peuvent prendre entre 4 et 16s pour leur première exécution, j'ai donc préféré les créer dans d'autres threads (worker ou pas selon les cas) et faire le setVisible dans l'EDT.

Ce que tu dit, natha, me semble logique mais je suis rempli de confusions car les règles relatives à l'EDT ne sont expliquées clairement et précisément nulle part :(

En provenance du tutoriel Swing sur le site de Sun :

Citation:

---

Why does not the initial thread simply create the GUI itself? Because almost all code that creates or interacts with Swing components must run on the event dispatch thread.

---

Le lien : http://java.sun.com/docs/books/tutor...y/initial.html

Citation:

---

Envoyé par natha

Par contre rien n'empêche ensuite de créer tes frames et composants dans d'autres threads lorsque celà s'avère nécessaire car leur création prend du temps.

---

Comme je l'ai déjà dit je suis parfaitement d'accord avec toi.

D'ailleurs j'ai une application dont l'interface principale est créée dans l'EDT, mais dont une partie est construite à la volée en fonction des actions de l'utilisateur et elle bien construite dans un thread séparé.

Mais lors de la construction de cette partie j'ai du alterner des parties de code exécutées dans le thread et d'autres que je différais dans l'EDT. Si on fait tout dans le thread, certaines fonctions vont elle-mêmes poster des actions dans l'EDT (un setText() va poster un repaint() dans l'EDT). Sans ça, j'avais des parties de mon nouveau panel qui s'affichait avant que le panel soit lui-même dessiné (celles où j'avais fait le setText()).

En espérant avoir fait avancer un peu le shmilblick

Fred

Citation:

---

Envoyé par kwxyz

Mais lors de la construction de cette partie j'ai du alterner des parties de code exécutées dans le thread et d'autres que je différais dans l'EDT. Si on fait tout dans le thread, certaines fonctions vont elle-mêmes poster des actions dans l'EDT (un setText() va poster un repaint() dans l'EDT). Sans ça, j'avais des parties de mon nouveau panel qui s'affichait avant que le panel soit lui-même dessiné (celles où j'avais fait le setText()).

---

C'est dans ce genre de cas où l'utilisation d'un Worker est indiquée. Ca offre ce qu'il faut pour effectuer le traitement lourd dans un thread et interragir avec l'EDT à certains moments.

Citation:

---

Envoyé par natha

C'est dans ce genre de cas où l'utilisation d'un Worker est indiquée. Ca offre ce qu'il faut pour effectuer le traitement lourd dans un thread et interragir avec l'EDT à certains moments.

---

A bah tiens, voilà un truc que je ne connais pas.
J'y jetterai un œil à l'occasion, merci.

Fred

SwingWorker la classe, dans l'API depuis Java6, sinon c'est une classe à downloader sur le net.

Quelques infos complémentaire concernant SwingWorker :

• Tutoriel : SwingWorker (Java SE 6)
• La classe de Java 6 "backportée" pour Java 5.0 : https://swingworker.dev.java.net/
• La classe "historique" pour les versions antérieurs : SwingWorker.java
• Un de mes billets avec une petite application JWS de démo : SwingWorker à l'affiche

Sinon pour moi il n'y a rien de problématique à créer/modifier une JFrame dans un autre thread tant qu'elle n'est pas visible et qu'il n'y a aucune relation avec des composants visibles...

a++

Citation:

---

Sinon pour moi il n'y a rien de problématique à créer/modifier une JFrame dans un autre thread tant qu'elle n'est pas visible et qu'il n'y a aucune relation avec des composants visibles...

---

Justement, il n'y aucun garantie que l'implémentation ne fasse pas des choses qui devraient être faites dans l'EDT, donc il faut éviter cela.