EDT bloqué par System.in

Bonjour

Voici mon problème: lorsque j'attend une entrée utilisateur sur System.in, l'edt est totalement bloqué.
Je ne peux donc pas avoir d'interface graphique et prendre en même temps des inputs utilisateur sur System.in?

Voici le code qui montre le problème (exécutable):

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 32 33 34 35

import java.awt.Dimension; import java.io.IOException;   import javax.swing.JFrame; import javax.swing.JTextField;     public class Bug {   JFrame frame; JTextField txtIn;   Bug(){ frame = new JFrame("bug frame"); txtIn = new JTextField(); frame.add(txtIn); frame.setSize(new Dimension(50,50)); frame.setVisible(true); }   public static void main(String[] args) { //je lance l'ui Bug b = new Bug(); //je lance la lecture try { while(true){ // System.in.read(); } } catch (IOException e) { e.printStackTrace(); } }   }

---

Impossible d'écrire du texte dans le textfield sans devoir faire une entrée utilisateur.

J'ai essayé beaucoup de possibilité à base de thread, sans résultats sur le fond du problème.
ps: je sais que l'ui doit être fait avec invokeLater(), là c'est un exemple simple dans lequel invokeLater n'est pas la solution.


Le premier qui me montre comment faire marcher les deux, je lui dit un grand merci.

Je me demande bien pourquoi tu utilises System.in alors que tu as un JTextField pour la saisie. Ca m'échappe en fait.

C'est parce que System.in est déjà utilisé par une librairie.
Du coup je me fait une ui pour moi, pour ne pas interférer.

Je me suis fait un système non-bloquant qui me permet de fonctionner quand même (asser salement), mais je m'intéresse surtout au pourquoi du comment un read sur System.in me bloque mon edt.

L'exemple donné est pour montrer le mécanisme qui ne marche pas.

Dans ce cas elà il faut que ton System.in se passe dans un Thread séparé. En effet System.in est un appel bloquant, qui arrête tout ce qui peut se passer dans le Thread courant, dans ton cas l'EDT.
De fait toute tâche potentiellement bloquante/longue doit être effectué dans un Thread différent de l'EDT pour ne pas bloquer les opérations de dessins, les events et tout le toutim.

CF http://gfx.developpez.com/tutoriel/j...ing-threading/

Citation:

---

Envoyé par sinok

Dans ce cas elà il faut que ton System.in se passe dans un Thread séparé. En effet System.in est un appel bloquant, qui arrête tout ce qui peut se passer dans le Thread courant, dans ton cas l'EDT.

---

Le hic, c'est que le System.in ne se passe pas dans l'EDT, mais dans le thread principal :

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

Bug() { frame = new JFrame("bug frame"); txtIn = new JTextField(); frame.add(txtIn); frame.setSize(new Dimension(50, 50)); frame.setVisible(true); System.out.println("(c) => " + SwingUtilities.isEventDispatchThread()); }   public static void main(String[] args) { // je lance l'ui System.out.println("(a) => " + SwingUtilities.isEventDispatchThread()); Bug b = new Bug();   System.out.println("(b) => " + SwingUtilities.isEventDispatchThread()); // je lance la lecture try { while (true) { // System.in.read(); } } catch (IOException e) { e.printStackTrace(); } }

---

donne

Citation:

---

(a) => false
(c) => false
(b) => false

---

et bloque l'EDT tant qu'on n'a pas rentré qq chose dans la console.

ça ne devrais pas arriver. Cependant, toute opération sur les composant swing devant se faire dans l'EDT, pourrais-tu nous dire si le code suivant résouds ton problème?

Code:

---

1 2 3 4 5 6 7 8 9

Bug() { SwingUtilities.invokeLater(new Runnable(){ public void run(){ frame = new JFrame("bug frame"); txtIn = new JTextField(); frame.add(txtIn); frame.setSize(new Dimension(50, 50)); frame.setVisible(true); }}); }

---

Sinon j'ai testé en local, le code que tu donne marche parfaitement chez moi. Si t'es sous linux, effectue un kill -3 <pid> et donne nous le stacktrace que tu obtiens.

Citation:

---

Envoyé par tchize_

Sinon j'ai testé en local, le code que tu donne marche parfaitement chez moi. Si t'es sous linux, effectue un kill -3 <pid> et donne nous le stacktrace que tu obtiens.

---

Ah
Sous windows(edit: xp), avec le jre 1.6.0_2 et 1.6.0_20, ça ne marche pas.
Si sous linux cela marche, je suspecte un bug du jre.
Je vais faire différents tests, je posterais mes résultats après.

quand j'ai testé, c'était sous windows 7 ;)