JFrame et GarbageCollector

Bonjour,

J'ai juste une petite interrogation par rapport aux JFrame :

Mettons que je fasse un setVisible(false) sur une JFrame, puis que celle-ci ne soit plus référencée, càd qqc comme :

Code:

---

1 2 3 4

JFrame f = new JFrame(); ... f.setVisible(false); f = null;

---

en gros.

Est-ce que la JFrame sera garbage collectée ?

Merci :D

Comme tout objet java, il est nettoyable par le GC dès qu'il n'y a plus de référence qui permette de l'atteindre. Donc en gros, quand il n'est plus à l'écran et que ton code n'y fait plus référence.

Ok.

Je me posais la question parce qu'une fenêtre non référencée mais visible ne sera pas garbage collectée (fort heureusement)...

Merci pour tes explications.

Citation:

---

Envoyé par tchize_

Comme tout objet java, il est nettoyable par le GC dès qu'il n'y a plus de référence qui permette de l'atteindre. Donc en gros, quand il n'est plus à l'écran et que ton code n'y fait plus référence.

---

Salut,

je pensais qu'il fallait faire un dispose() pour ça (qu'un setVisible(false) n'était pas suffisant que toutes les références internes à SWING sur la JFrame soient supprimées)

Euh... Conclusion ?

Salut,

Citation:

---

Envoyé par Sharcoux

Je me posais la question parce qu'une fenêtre non référencée mais visible ne sera pas garbage collectée (fort heureusement)...

---

En fait il existe toujours une référence vers une fenêtre visible...

Citation:

---

Envoyé par joel.drigo

je pensais qu'il fallait faire un dispose() pour ça (qu'un setVisible(false) n'était pas suffisant que toutes les références internes à SWING sur la JFrame soient supprimées)

---

Il faut bien appeler dispose() pour complètement libérer les ressources utilisées par la fenêtre.
Mais il ne s'agit pas de ressources géré par le Garbage Collector, mais de ressource système.


a++

Citation:

---

Envoyé par adiGuba

Il faut bien appeler dispose() pour complètement libérer les ressources utilisées par la fenêtre.
Mais il ne s'agit pas de ressources géré par le Garbage Collector, mais de ressource système.

---

Ca c'est ce que dit clairement la doc. En revanche, ce qui est moins clair, c'est si un setVisible(false) est invoqué et que le code appelant n'a plus de référence sur la frame, c'est qu'elle puisse être "garbagée" (j'entends par là "éligible comme libérable par le Garbage Collector") dans ce cas : ce qui signifie qu'on pourrait permettre de libérer une frame dont les ressources système associées non pas été libérées.
C'est juste pour comprendre et savoir... dans l'absolu, à mon avis, il ne faut jamais perdre une référence sur une jframe sans l'avoir disposée, ou s'être arranger pour qu'elle le soit, par un frame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE) par exemple. Un appel à setVisible(false) n'étant nécessaire que si on veut pourvoir réafficher la jframe.

le dispoe set si tu veux libérer les ressources système tout en gardant une référence vers ta fenêtre. Par exemple, tu as une fenêtre avec beaucoup d'images / icones, etc, mais tu ne l'affiche que de temps e temps. Entre deux, tu peux faire un dispose(), le prochain appel à setVisible(true) recréera les ressources système.

Oui, une fenetre non visible où dispose() n'a pas été appelé et pour laquelle le GC peux la collecter libèrera ses ressources système lors du passage du gc. dispose() permet juste de le faire plus tôt.


Conclusion: une JFrame au niveau du GC se comportent comme n'importe quel autre objet. Il faut juste faire attention qu'en interface graphique, on oublie vite une référence à gauche ou à droite. Par exemple , on oublie vite que la fenetre visible et inévitablement enregistrée dans l'event dispatcher :)

Désolé, je vous ai perdu...

Si je fais

Code:

---

1 2 3 4 5 6 7

JFame f = new JFrame(); f.setVisible(true); ... //2-3 traitements sans conséquences ... f.setVisible(false); f = null;

---

J'aurai donc le même résultat après passage du GC que si je fais :

Code:

---

1 2 3 4 5 6

JFame f = new JFrame(); f.setVisible(true); ... //2-3 traitements sans conséquences ... f.dispose();

---

J'ai bien compris ?

Je pose la question parce que je suis en face d'un code que je n'ai pas écrit et qui n'utilise que des f.setVisible(false) à la place de dispose() et que je me demande si ça peut finir par créer un problèmes.

Citation:

---

Envoyé par tchize_

le dispoe set si tu veux libérer les ressources système tout en gardant une référence vers ta fenêtre. Par exemple, tu as une fenêtre avec beaucoup d'images / icones, etc, mais tu ne l'affiche que de temps e temps. Entre deux, tu peux faire un dispose(), le prochain appel à setVisible(true) recréera les ressources système.

Oui, une fenetre non visible où dispose() n'a pas été appelé et pour laquelle le GC peux la collecter libèrera ses ressources système lors du passage du gc. dispose() permet juste de le faire plus tôt.


Conclusion: une JFrame au niveau du GC se comportent comme n'importe quel autre objet. Il faut juste faire attention qu'en interface graphique, on oublie vite une référence à gauche ou à droite. Par exemple , on oublie vite que la fenetre visible et inévitablement enregistrée dans l'event dispatcher :)

---

Ok ! Merci :D Moi qui avait toujours compris l'inverse :o Surtout que je bosse surtout en SWT que pour le coup c'est carrément l'inverse... le dispose est obligatoire parce que le setVisible(false) va en effet permettre au shell d'être supprimé de la mémoire sans que le handle système ne soit libéré

Citation:

---

Envoyé par Sharcoux

J'ai bien compris ?

---

Non, du tout, ça n'a rien à voir. Le dispose libère les ressources système, ce qui n'influence pas le GC

Citation:

---

Envoyé par tchize_

Oui, une fenetre non visible où dispose() n'a pas été appelé et pour laquelle le GC peux la collecter libèrera ses ressources système lors du passage du gc. dispose() permet juste de le faire plus tôt.

---

Je ne suis pas sûr de cela.

Tant que la fenêtre n'a pas été disposée, elle reste référencée via le framework Swing (via Window.getWindow()) car elle peut comporter des ressources non-géré par le GC (lié à l'écran ou autre).

Le GC ne peut s'occuper que de ce qui touche la mémoire. rien de plus.
Là on parle de ressources géré par le système d'exploitation hôte (les fenêtres), ce qui est en dehors des capacités du GC.


a++

je suis tombé il y a deux jours sur un bug report qui datait de l'époque sun, où il était indiqué qu'en faisant ceci:

Code:

---

1 2 3 4 5 6

for (int i=0; i< 10; i++){ MaFrame f = new MaFrame(); f.setVisible(true); thread.sleep(1000); f.setVisible(false); // enfin c'était dans swingutilities, je simplifie }

---

On constatait que certains fenêtres n'étaient pas GC (pas d'appel à la méthode finalize()) => sun avait reconnu le bug, donc oui, selon moi, le dispose n'est pas nécessaire pour que la fenetre soit GC. Je ne trouve pas de doc qui prétende le contraire chez oracle. Il n'est fait mention nulle part du GC dans dispose(), par exemple.

Citation:

---

Envoyé par tchize_

Non, du tout, ça n'a rien à voir. Le dispose libère les ressources système, ce qui n'influence pas le GC

---

Ben... Si le dispose() libère les ressources, ça veut dire que le GC n'aura pas à le faire, non ? Enfin, je dis ça parce que pour moi le rôle du GC c'est de libérer les ressources qui ne risquent plus de servir. Mais j'ai peut-être mal compris là aussi... Ou j'ai mal compris ta remarque... Ou les deux...

Citation:

---

Envoyé par tchize_

je suis tombé il y a deux jours sur un bug report qui datait de l'époque sun,

---

Attention aux vieux bugs qui ne représentent pas forcément le fonctionnement des versions plus récentes.

Par exemple jusqu'à Java 5 on peut voir que les JFrames utilisaient le système de finalisation.
Toutefois c'est à la fois très contraignant et très dangereux à utiliser, et depuis Java 6 il n'y a plus rien de tel.
On peut le voir via la javadoc, dans la version 5 finalize() était redéfinie dans Frame, alors que ce n'est plus le cas désormais :
http://docs.oracle.com/javase/1.5.0/...ng/JFrame.html
http://docs.oracle.com/javase/6/docs...ng/JFrame.html


Pour moi il faut donc appeler explicitement dispose() ou utiliser DISPOSE_ON_CLOSE...

Citation:

---

Envoyé par Sharcoux

Ben... Si le dispose() libère les ressources, ça veut dire que le GC n'aura pas à le faire, non ? Enfin, je dis ça parce que pour moi le rôle du GC c'est de libérer les ressources qui ne risquent plus de servir. Mais j'ai peut-être mal compris là aussi... Ou j'ai mal compris ta remarque... Ou les deux...

---

Le GC libère UNIQUEMENT la mémoire utilisé par les objets Java.
Mais ce n'est pas la seule ressource qui peut être utilisé par un programme !

Les JFrames utilisent d'autres types de ressources lié à l'environnement graphique du système hôte.
Ces ressources ne sont pas donc gérées par le GC, et doivent donc être libéré explicitement, d'où l'intérêt du dispose().


a++

@adiGuba : Merci pour les précisions sur le GC.

Pour ma part, je ne sais pas qui de vous à raison au final, mais moi je vais mettre des dispose() partout, dans le doute... :ccool:

En tout cas, merci beaucoup pour votre investissement, et si la question vous intéresse toujours, je serai curieux de continuer à lire vos points de vue sur la question.

Merci encore.

ce n'est pas parce qu'il n'y a plus de finalizer dans la jframe qu'elle ne libère plus ses ressources. La frame est référencée dans de nombreuses weakreferences. Hors on peut aussi faire du boulot de nettoyage via ces weakreferences. Je reste d'avis: sans un document me disant que le dispose est nécessaire, que le GC ne suffit pas, pour moi, ça relève juste de la légende urbaine :)

Citation:

---

Envoyé par tchize_

ce n'est pas parce qu'il n'y a plus de finalizer dans la jframe qu'elle ne libère plus ses ressources. La frame est référencée dans de nombreuses weakreferences. Hors on peut aussi faire du boulot de nettoyage via ces weakreferences. Je reste d'avis: sans un document me disant que le dispose est nécessaire, que le GC ne suffit pas, pour moi, ça relève juste de la légende urbaine :)

---

Et je te dirais l'inverse : sans un document me disant que le dispose est inutile, je continuerais de le recommander. Et croire que le GC s'en occupe relève de la légende urbaine ;)

Le GC s'occupe d'une seule et unique ressource : la mémoire occupé par les objets Java.

Tous les autres types de ressources doivent être libérés explicitement.
Et généralement le fait d'utiliser le GC pour gérer autre chose est une mauvaise idée...


a++