Swing Wird invisible, nicht-ref. Fenster vom GC entfernt?

[jakob190590]

Hallo,

ich bin mir grade unsicher, ob ich das machen darf:
Ein Fenster (JInternalFrame) nicht dispose() 'en, auch wenn ich es nicht mehr brauche.

Oder anders gesagt:
Wird ein nicht-referenziertes und unsichtbares Fenster vom Garbage-Collector entfernt, auch wenn nicht dispose() aufgerufen wurde? (Sollte es ja, weil es dann unbrauchbar ist für mich.)


Ich hoffe ihr versteht mein Problem, ich hab eben Angst, dass mich in dem Fall der GC im Stich lässt.
Danke schon mal für die Antworten!

 

[Gast2]

Hm ich bezweifel dass du alle Referenzen auf den Frame loswirst wenn du einfach nur mit setVisible(false); arbeitest.
dispose() räumt intern noch ein wenig auf.

 

[FArt]

Ich hoffe ihr versteht mein Problem, ich hab eben Angst, dass mich in dem Fall der GC im Stich lässt.
Danke schon mal für die Antworten!

Keine Angst!

Das kannst du ohne viel Aufwend selber herausfinden: Mache einen Heap-Dump deiner laufenden Applikation, suche dir das unsichtbare Objekt und schaue wer es wie referenziert.

Bei einer harten Referenz wird der GC es nicht löschen, sonst kann es bei Bedarf gelöscht werden.

Die Antwort lässt sich übrigens auch nur über Sourcecode lesen (steht ja alles zur Verfügung) finden!

Stell doch mal eine begründete Behauptung auf, dann lässt es sich viel besser diskutieren.

 

[jakob190590]

Ok, danke FArt:
Selber rausfinden mit Heap-Dump, da hab ich keine Ahnung wie das geht, das einzige was mir dazu eingefallen wäre ist im TaskManager den Speicherbedarf des Progs zu überwachen...

Wo ich im SourceCode schauen muss weiß ich ehrlich gesagt auch nicht. Bei dispose() nicht, weil das ruf ich ja nicht auf, wo sonst? System.gc()?

Meine Befürchtung, dass der GC da nicht waltet, rührt eben daher, dass in der API zu dispose() steht, dass die Methode die Ressourcen freigibt. Warum gibt es die Methode, wenn es (hoffentlich) sowieso der GC macht? Weiter begründen kann ich das nicht ^^

Ich hab eigentlich nur folgenden Aufruf...

// methoden-anfang
MyInternalFrame mif = new MyInternalFrame();
mif.setDefaultCloseOperation(JInternalFrame.HIDE_ON_CLOSE); // wird eben nicht dispose() 'd
mif.setVisible(true);
// methoden-ende

aber je länger ich drüber nachdenke, desto mehr glaube ich auch, dass der GC des entfernt, wenn das Frame wieder vom User unsichtbar gemacht wird.

Danke jedenfalls nochmal!

 

[Gastredner]

Meine Befürchtung, dass der GC da nicht waltet, rührt eben daher, dass in der API zu dispose() steht, dass die Methode die Ressourcen freigibt. Warum gibt es die Methode, wenn es (hoffentlich) sowieso der GC macht? Weiter begründen kann ich das nicht ^^

Vermutlich, weil es sich um native Resourcen handelt:

void java.awt.Window.dispose()

Releases all of the native screen resources used by this Window, its subcomponents, and all of its owned children. That is, the resources for these Components will be destroyed, any memory they consume will be returned to the OS, and they will be marked as undisplayable.

Ich kann mir eigentlich auch nicht vorstellen, dass der GC ein nicht freigegebenes Window entfernt - in diesem Falle blieben die nativen Resourcen ja weiterhin reserviert, was eigentlich nicht sein sollte. Ich fände es schwer zu glauben, dass die Entwickler solch ein Problem übersehen haben sollten.

 

[darkeye2]

Was spricht eigentlich dagegen das frame mit dispose zu löschen? bzw mit EXIT_ON_CLOSE ? Wenn man den sinn sehen würde es nicht zu benutzen ist es wahrscheinlich auch einfacher dein problem nach zu vollziehen.

 

[jakob190590]

Ich kann mir eigentlich auch nicht vorstellen, dass der GC ein nicht freigegebenes Window entfernt - in diesem Falle blieben die nativen Resourcen ja weiterhin reserviert, was eigentlich nicht sein sollte. Ich fände es schwer zu glauben, dass die Entwickler solch ein Problem übersehen haben sollten.

Aber die Entwickler dürften doch auch nicht übersehen, dass ein Fenster für immer im RAM bleibt, wenn ich nicht dispose() aufrufe. Das darf doch auch nicht sein...

Was spricht eigentlich dagegen das frame mit dispose zu löschen? bzw mit EXIT_ON_CLOSE ?

Der Grund ist folgender: Das Frame stellt eine Suchfunktion bereit und kann als "StandAlone-InternalFrame" verwendet werden, aber auch per API von anderen Programmteilen.
Wenn es von anderen Programmteilen verwendet wird, darf nicht DISPOSE_ON_CLOSE eingestellt sein, weil es vllt noch gebraucht wird! Man könnte natürlich die DefaultCloseOperation ändern, aber das ist in dem Fall umständlich und fehleranfällig.

Ich will einfach nur wissen, ob man dispose() aufrufen muss, wenn man ein Frame nicht mehr braucht.

 

[Gastredner]

Wenn es von anderen Programmteilen verwendet wird, darf nicht DISPOSE_ON_CLOSE eingestellt sein, weil es vllt noch gebraucht wird!

Und wo ist das Problem? Bereits freigegebene Fenster können laut Javadoc ja jederzeit wieder genutzt werden.

 

[Atze]

ich versteh den gedanken in deinem fall mal garnicht. vielleicht bin ich grad auch zu unnüchtern 😀 , aber das ist eine desktopanwendung, oder? wo ein üser dran arbeitet? oder eine methode auf dem server? multiuser?
wenn es ne desktopanwendung ist, warum greift dann die api irgendwie auf die gui der suche zu, wenn der user das fenster geschlossen hat? und wenn es eine serveranwendung ist, teilen sich da mehrere user ein suchfenster? 🙂 ich grübel die ganze zeit, aber ich komm nich drauf, wie das szenario da ist! 🙂 sorry wenn ich einfach zu blöd bin! 🙂

 

[jakob190590]

Und wo ist das Problem? Bereits freigegebene Fenster können laut Javadoc ja jederzeit wieder genutzt werden.

Aber es kann doch nicht die gleiche Instanz wieder angezeigt werden! dispose() und dann setVisible(true) zeigt mir eindeutig kein Fenster an.

, aber das ist eine desktopanwendung, oder? wo ein üser dran arbeitet? oder eine methode auf dem server? multiuser?
wenn es ne desktopanwendung ist, warum greift dann die api irgendwie auf die gui der suche zu, wenn der user das fenster...

Es ist eine Desktopanwendung, hat nichts mit Server zu tun. Die API (also Methoden, Attribute) die mein InternalFrame bereitstellt, ist für andere Programmteile (z.B. Frames) der GLEICHEN Anwendung! (Das nennt man doch auch API?)

 

[Atze]

also unter api verstehe ich meist den core des projekts, ja, wo wie du sagst, die methoden und attribute von der gui (den frames) benutzt werden. und dein suchframe stellt sie wie bereit? dann haben die anderen frames doch sicher referenzen auf darauf, oder? es sein denn, diese anderen frames wären auch zerstört. also hast du immer eine referenz, solange du sie brauchst, auch wenn du das fenster nicht mehr siehst. ich finds aber immernoch komisch, dass ein fenster schnittstellen bietet! 🙂

 

[jakob190590]

also unter api verstehe ich meist den core des projekts, ja, wo wie du sagst, die methoden und attribute von der gui (den frames) benutzt werden. und dein suchframe stellt sie wie bereit? dann haben die anderen frames doch sicher referenzen auf darauf, oder? es sein denn, diese anderen frames wären auch zerstört. also hast du immer eine referenz, solange du sie brauchst, auch wenn du das fenster nicht mehr siehst. ich finds aber immernoch komisch, dass ein fenster schnittstellen bietet! 🙂

es ist nicht komisch, dass eine suchfunktion (samt fenster) von einem anderen Programmteil genutzt wird und daher schnittstellen bieten muss. ich will das gar nicht diskutieren, du kennst ja mein projekt nicht.