Discussion :

[Julien Bodin]

Bonjour à tous !

Je développe un bon gros client lourd sous Swing et il arrive de temps en temps (souvent ?) que l'application freeze complètement et que le seul moyen pour l'éteindre soit de killer la JVM.

J'essaie pourtant d'être prudent avec l'EDT mais ce n'est pas toujours simple.

Est-il possible que ces freezes soient liés à autre chose que l'EDT ? Sachant qu'en général l'application freeze lorsqu'on clique sur un bouton censé ouvrir une nouvelle fenêtre.

L'application ne se fige pas forcément à chaque fois. Un même bouton ne fera planter l'application qu'au bout de plusieurs minutes ou heures et c'est quelque chose que j'ai du mal à comprendre.

Comment débugger efficacement ces plantages, histoire de voir à quels endroits un invokeLater() serait utile par exemple ?

Je vous remercie d'avance pour votre aide

[uhrand]

J'essaie pourtant d'être prudent avec l'EDT mais ce n'est pas toujours simple.

Essaie de faire tourner en arrière plan uniquement les calculs, accès fichiers, constructions de listes, etc. sans jamais toucher un truc de la surface graphique. Et seulement après, quand ce travail d'arrière plan est terminé, tu affiche l'interface graphique sur l'EDT. En d'autres mots, essaie de séparer complètement les deux choses: calculs (doInBackground) et graphiques (done).

Utilise le "SwingWorker" et essaie d'éviter les "invokeLater".

[Julien Bodin]

Utilise le "SwingWorker" et essaie d'éviter les "invokeLater".

Parce que le "invokeLater" est symptomatique d'une "mauvaise" conception ?

[sinok]

Parce que le "invokeLater" est symptomatique d'une "mauvaise" conception ?

Non, pas du tout.

C'est juste que le SwingWorker englobe toute la gestion des invokeLater, donc te simplifie le travail .

[uhrand]

Parce que le "invokeLater" est symptomatique d'une "mauvaise" conception ?

SwingWorker est généralement recommandé pour les travaux en arrière plan. "invokeLater" a tendance à compliquer terriblement les choses jusqu'au point de ne plus pouvoir s'en sortir. De ce point de vue c'est peut-être (mais pas toujours!) symptomatique d'une mauvaise conception.

[Julien Bodin]

J'ai trouvé quelques bouts de codes intéressant sur cet article.

On y trouve une classe CheckThreadViolationRepaintManager qui est un RepaintManager détectant les violations de l'EDT.

Il présente aussi une autre méthode en se basant sur l'AOP.

Je vous met le code de cette classe :

Code :

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

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
36
37
38
39
40
41
42
43
44
public class CheckThreadViolationRepaintManager extends RepaintManager {
    // it is recommended to pass the complete check  
    private boolean completeCheck = true;
 
    public boolean isCompleteCheck() {
        return completeCheck;
    }
 
    public void setCompleteCheck(boolean completeCheck) {
        this.completeCheck = completeCheck;
    }
 
    public synchronized void addInvalidComponent(JComponent component) {
        checkThreadViolations(component);
        super.addInvalidComponent(component);
    }
 
    public void addDirtyRegion(JComponent component, int x, int y, int w, int h) {
        checkThreadViolations(component);
        super.addDirtyRegion(component, x, y, w, h);
    }
 
    private void checkThreadViolations(JComponent c) {
        if (!SwingUtilities.isEventDispatchThread() && (completeCheck || c.isShowing())) {
            Exception exception = new Exception();
            boolean repaint = false;
            boolean fromSwing = false;
            StackTraceElement[] stackTrace = exception.getStackTrace();
            for (StackTraceElement st : stackTrace) {
                if (repaint && st.getClassName().startsWith("javax.swing.")) {
                    fromSwing = true;
                }
                if ("repaint".equals(st.getMethodName())) {
                    repaint = true;
                }
            }
            if (repaint && !fromSwing) {
                //no problems here, since repaint() is thread safe
                return;
            }
            exception.printStackTrace();
        }
    }
}

Il suffit ensuite au démarrage de l'application de faire :

Code :

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

RepaintManager.setCurrentManager(new CheckThreadViolationRepaintManager());

L'auteur présente également une autre solution au cas où vous utiliseriez déjà un RepaintManager.

Merci pour vos réponses et votre aide. J'espère un jour venir à bout de tous ces freezes