Discussion :

[Tsunamy]

Bonjour à tous!
je suis en train de développer une application en java, j'ai utilisé plusieurs notions : swing comme interface graphique, je manipule des fichiers xml, connexion jdbc...
le problème est que si je quitte mon application, le processus javaw.exe relatif ne se ferme pas!!!
je me suis dis que peut être celà est dû a une ressource qui est encore ouverte (un Frame, conexion jdbc...)!
pourriez vous, svp, me donner des pistes des idées sur ce point?
quel partie du code revoir pour être sûr de la libération totale du processus?
parce que le code deviens de plus en plus long et j'arrive pas suivre l'erreur
merci d'avance

[dim1205]

Bonjour

Il faut mettre un System.exit(0) dans ton actionPerformed du bouton "Quitter" ou de l'action

[Tsunamy]

Bonjour

Il faut mettre un System.exit(0) dans ton actionPerformed du bouton "Quitter" ou de l'action

merci bcp ça marche
j'ai mis System.console(); par inattention au lieu de System.exit(0)

[Deadpool]

Bonjour,

Comment tu fermes ta fenêtre graphique? Tu as un bouton dédié? Tu appuie sur la croix en haut à droite (en supposant que tu es sous Windows)?

[adiGuba]

Salut,


Lorsque tu utilises Swing, un thread (l'EDT) est automatiquement créer pour gérer l'interface graphique. Ce thread effectue ses tâches en boucle à l'infini.

Tu dois donc soit appeler explicitement System.exit(), soit utiliser setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) sur ta JFrame, ce qui fera la même chose à la fermeture de la fenêtre...

a++

[Tsunamy]

merci les gars pour vos réponses!
le System.exit() et setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) font l'affaire

[sinok]

Salut,


Lorsque tu utilises Swing, un thread (l'EDT) est automatiquement créer pour gérer l'interface graphique. Ce thread effectue ses tâches en boucle à l'infini.

Tu dois donc soit appeler explicitement System.exit(), soit utiliser setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) sur ta JFrame, ce qui fera la même chose à la fermeture de la fenêtre...

En fait pas trop non plus, si aucun composant est affiché, que plus rien ne traîne dans les Stack de l'EDT(events natifs ou java), l'EDT se termine tout seul comme un grand (bon c'ewt AWT qui s'en occupe) sans passer par un EXIT_ON_CLOSE (la seule exception à ça est une mauvaise conception de java web start qui fout un poil la merde sur la façon dont l'EDT s'arrête, mais çà c'est une autre histoire).

Bon ensuite ça ne garatit rien s'il reste de threads autres en mêmoire, ou encore si les composants n'ont pas été disposés mais juste cachés avec un setVisible false.

Le fait de devoir utiliser un System.exit pour terminer une application java signifie que quelque chose ne tourne pas rond dans un son code (sauf sous web start.


Plus d'infos dans les liens suivants:
http://www.pushing-pixels.org/?p=232
http://www.pushing-pixels.org/?p=369

[adiGuba]

l'EDT se termine tout seul comme un grand

Tiens j'ignorai que le thread de l'EDT pouvait s'arrêter automatiquement...

Bon ensuite ça ne garatit rien s'il reste de threads autres en mêmoire, ou encore si les composants n'ont pas été disposés mais juste cachés avec un setVisible false.

Par défaut la fermeture des fenêtres se contente de les cacher... donc cela n'arrête pas l'EDT.

Le fait de devoir utiliser un System.exit pour terminer une application java signifie que quelque chose ne tourne pas rond dans un son code (sauf sous web start.

Je ne suis pas vraiment d'accord là dessus. Un system.exit(0) est tout à fait propre et permet justement de s'assurer de la bonne fermeture de l'application (on n'a pas de thread non-daemon qui viendrait nous embêter).

a++

[sinok]

En fait à partir de java 1.4 les helper threads sont terminés par AWT

“Prior to 1.4, the helper threads were never terminated.Starting with 1.4, the behavior has changed as a result of the fix for 4030718. With the current implementation, AWT terminates all its helper threads allowing the application to exit cleanly when the following three conditions are true:
* There are no displayable AWT or Swing components.
* There are no native events in the native event queue.
* There are no AWT events in java EventQueues.”

cf http://java.sun.com/javase/6/docs/ap...eadIssues.html

Je ne suis pas vraiment d'accord là dessus. Un system.exit(0) est tout à fait propre et permet justement de s'assurer de la bonne fermeture de l'application (on n'a pas de thread non-daemon qui viendrait nous embêter).

Perso je trouve ça un poil bourrin, on ne sait jamais, un thread daemon pourrait être en train de réaliser telle ou telle opération, et l'arrêter de force en plein milieu de sa tâche pourrait poser des problèmes (bon, objectivement, en général on évite de laisser des threads tourner comme ça, donc le System.exit passe, mais dans certains cas le dispose assure que la JVM ne se terminera que quand toutes les actions qu'elle a à réaliser se terminent correctement).

Mais j'ai l'impression que c'est pas la première fois qu'on en parle d'ailleurs.

[adiGuba]

Perso je trouve ça un poil bourrin, on ne sait jamais, un thread daemon pourrait être en train de réaliser telle ou telle opération, et l'arrêter de force en plein milieu de sa tâche pourrait poser des problèmes

Mais ce serait le cas avec seulement des dispose() : le thread de l'EDT n'est pas un daemon thread, et c'est pour cela qu'il peut empêcher la fin du programme.

Lorsqu'il n'y a plus de thread non-daemon, tous les threads daemon sont stoppé...

(bon, objectivement, en général on évite de laisser des threads tourner comme ça, donc le System.exit passe, mais dans certains cas le dispose assure que la JVM ne se terminera que quand toutes les actions qu'elle a à réaliser se terminent correctement).

Seulement les actions de l'EDT

Et puis de toute manière si on a des traitements à faire à la fermeture, il est préférable de passer par les ShutdownHook

Mais j'ai l'impression que c'est pas la première fois qu'on en parle d'ailleurs.

Pas avec moi (ou alors j'ai oublié )

a++