finalizie() bei JInternalFrame wird nicht aufgerufen !

[Spontex]

Hallo,

ich habe hier bei einer Klasse die von JInternalFrame abgeleitet wird bei der die Methode protected finalizie() nicht aufgerufen wird.
Die Klasse ist ein Singelton damit ich von überall zugriff darauf habe und z.B. wenn sie schon geladen ist aber im Hintergerund steht, wieder nach vorne zu holen. Dazu benutze ich wiederum ein flag

private static boolean m_State;

welches ich gerne in finalizie() zurücksetzten möchte. Hier ein Beispiel um das ganze zu verdeutlichen:

CStart.java

public class CStart {

	public static void main(String[] args) {
		CMainFrame app = new CMainFrame();
	}
}

CMainFrame.java

import java.awt.BorderLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.beans.PropertyVetoException;

import javax.swing.JButton;
import javax.swing.JDesktopPane;
import javax.swing.JFrame;
import javax.swing.JInternalFrame;
import javax.swing.JPanel;


public class CMainFrame extends JFrame implements ActionListener {

	private JPanel m_Panel;
	private JDesktopPane m_Desktop;
	private JButton m_Button1;
	private JButton m_Button2;
	
	public CMainFrame () {
		m_Panel = new JPanel(new BorderLayout());
		m_Desktop = new JDesktopPane();
		
		m_Button1 = new JButton ("Zeige oder lade erstes Fenster");
		m_Button1.setActionCommand("actionbtnWindow1");
		m_Button1.addActionListener(this);
		m_Button2 = new JButton ("Zeige oder lade zweites Fenster");
		m_Button2.setActionCommand("actionbtnWindow2");
		m_Button2.addActionListener(this);
		
		m_Panel.add(m_Button1, BorderLayout.NORTH);
		m_Panel.add(m_Button2, BorderLayout.SOUTH);
		m_Panel.add(m_Desktop, BorderLayout.CENTER);
		
		this.setContentPane(m_Panel);
		this.setLocation(100,100);
		this.setSize(800, 600);
		this.setVisible(true);
	}
	


	public void actionPerformed(ActionEvent event) {
		String action = event.getActionCommand();
		Object item = event.getSource();
		
		if (item instanceof JButton) {

			if (action.equals("actionbtnWindow1")) {
				this.setWindow1();
			}
			else if (action.equals("actionbtnWindow2")) {
				this.setWindow2();
			}
		}
	}
	
	
	private void setWindow1() {
		System.out.print("\n(1) Status vorher: " + CTestFrame1.getState());
		
		if (CTestFrame1.getState()) {
			try {
				CTestFrame1.getInstance().setSelected(true);
			} catch (PropertyVetoException e) {
				e.printStackTrace();
			}
			
		} else {
			this.addChildFrame(CTestFrame1.getInstance(), 30);
		}
		
		System.out.print("\n(1) Status nachher: " + CTestFrame1.getState());
	}
	
	private void setWindow2() {
		System.out.print("\n(2) Status vorher: " + CTestFrame1.getState());
		
		if (CTestFrame2.getState()) {
			try {
				CTestFrame2.getInstance().setSelected(true);
			} catch (PropertyVetoException e) {
				e.printStackTrace();
			}
			
		} else {
			this.addChildFrame(CTestFrame2.getInstance(), 60);
		}
		
		System.out.print("\n(2) Status nachher: " + CTestFrame1.getState());
	}
	
	private void addChildFrame(JInternalFrame fChild, int iLocation) {
		fChild.setLocation(iLocation, iLocation/2);
		fChild.setDefaultCloseOperation(JInternalFrame.DISPOSE_ON_CLOSE);
		fChild.setClosable(true);
		fChild.setIconifiable(true);
		fChild.setMaximizable(true);
		fChild.setResizable(true);
		m_Desktop.add(fChild);
		fChild.setVisible(true);
		fChild.show();
	}
}

CTestFrame1.java

import java.awt.Dimension;
import javax.swing.JInternalFrame;


public class CTestFrame1 extends JInternalFrame{

	private static CTestFrame1 m_Frame;

	private static boolean m_State;
	
	private CTestFrame1() {
		this.setTitle("Erstes Fenster");
		Dimension dimSize = new Dimension(640, 480);
		this.setSize(dimSize);
		this.setMinimumSize(dimSize);
	}
	
	public static synchronized CTestFrame1 getInstance() {
		if (m_Frame == null) {
			m_Frame = new CTestFrame1();
		}
		m_State = true;
		return m_Frame;
	}

	public static synchronized boolean getState() {
		return m_State;
	}
	
	
	protected void finalize() {
		m_State = false;
	}
}

CTestFrame2.java

import java.awt.Dimension;
import javax.swing.JInternalFrame;

public class CTestFrame2 extends JInternalFrame{

	private static CTestFrame2 m_Frame;

	private static boolean m_State;
	
	private CTestFrame2() {
		this.setTitle("Zweites Fenster");
		Dimension dimSize = new Dimension(640, 480);
		this.setSize(dimSize);
		this.setMinimumSize(dimSize);
	}
	
	public static synchronized CTestFrame2 getInstance() {
		if (m_Frame == null) {
			m_Frame = new CTestFrame2();
		}
		m_State = true;
		return m_Frame;
	}

	public static synchronized boolean getState() {
		return m_State;
	}
	
	protected void finalize() {
		m_State = false;
	}
}

Und wo ich schon mal hier bin :wink: noch ein weiter Frage:
Ich lade per Default das SystemLookAndFeel kann aber auch zum DefaultLookAndFeel, was ja Java/Metal LnF sein sollte, umschalten. Das klappt auch wunderbar nur sind dann alle Swing komponenten die von AWT abgeleitet sind z.B. JFrame im nativen LookAndFeel und nehmen nicht das neue an.
Kann diese AWT/Swing komponenten irgendwie das andere LookAndFeel aufzwingen?

Freundliche Grüsse und danke
Spontex

 

[0xdeadbeef]

Die Methode finalize wird erst aufgerufen, wenn der Garbage Collector das Objekt tatsächlich zerstört, nicht schon dann, wenn man die Referenz auf null setzt.
U.u. kann man dem Garbage Collector aber auf die Sprünge helfen:

System.gc();

Was das Look and Feel angeht: um das LnF im Betrieb zu ändern, muß man updateComponentTreeUI für jeden Top-Level-Container aufrufen. Anschließend kann ein Resize der Container notwendig sein, weil die darin enthaltenen Komponenten ihre Größe geändert haben können:

UIManager.setLookAndFeel(lnfName);
SwingUtilities.updateComponentTreeUI(frame);
frame.pack();

 

[Roar]

finalize() sollte nicht benutzt werden, schon gar nicht wenn davon der verlauf des programms abhängt, da du nie weißt wann und ob finalize() überhaupt aufgerufen wird.

 

[Spontex]

Die Methode finalize wird erst aufgerufen, wenn der Garbage Collector das Objekt tatsächlich zerstört, nicht schon dann, wenn man die Referenz auf null setzt.
U.u. kann man dem Garbage Collector aber auf die Sprünge helfen:

System.gc();

Ich hatte eigentlich gedacht dass das Objekt, also der JInternalFrame zerstört wird da ich ihn auf DISPOSE_ON_CLOSE stehen habe. Und wenn ich nach dem schliessen das DesktopPane auf die Anzahl seiner Elemente abfrage

System.out.print(m_Desktop.getAllFrames().length)

bekomme ich 0 zurück. Und dann liegt der JInternalFrame immer noch im Speicher? Ist ja hart...

 

[Roar]

Und dann liegt der JInternalFrame immer noch im Speicher? Ist ja hart...

wieso hart? ein objekt liegt so lange im speicher rum bis es gelöscht wird. das is bei allen anderne programmeirsprachen auch so. sei froh dass du deine objekte nicht selbst löschen musst.
und da für die speicherverwaltung die VM zuständig ist und nicht das java programm kannst du aus deinem programm auch nicht manuell irgendwelche objekte löschen... zum glück...

 

[0xdeadbeef]

Er hat halt gedacht, daß finalize genauso funktioniert wie ein Destruktor. Dem ist aber nicht so und für C++-Programmierer ist das durchaus gewöhnungsbedürftig - viele halten es sogar für einen Mangel.

 

[Spontex]

wieso hart? ein objekt liegt so lange im speicher rum bis es gelöscht wird. das is bei allen anderne programmeirsprachen auch so. sei froh dass du deine objekte nicht selbst löschen musst.
und da für die speicherverwaltung die VM zuständig ist und nicht das java programm kannst du aus deinem programm auch nicht manuell irgendwelche objekte löschen... zum glück...

Mittlerweile wäre es mir fast lieber das ich alles selber löschen muss dann wüsste ich wenigstens was und auch wann es passiert (siehe weiter unten).

Er hat halt gedacht, daß finalize genauso funktioniert wie ein Destruktor. Dem ist aber nicht so und für C++-Programmierer ist das durchaus gewöhnungsbedürftig - viele halten es sogar für einen Mangel.

Irgendwie erhärtet sich bei mir der eindruck das der ganze GC ein Magel ist denn das löschen von Objekten scheint eher eine untergeordnete rolle zu spielen. Sein Name Garbage Collector tifft es schon ganz gut - er sammelt jeglichen Müll im Speicher ohne es zu löschen, scheinbar in der Hoffnung es irgendwann noch einmal verwenden zu können um so noch etwas Performance gut zu machen.

Da finalize() ja nicht so funktioniert wie ich erwartet hatte, habe ich das ganze nun auf einen InternalFrameListener umgestellt. Und um dem GC daraus auf die sprünge zu helfen das Objekt zu löschen. Das ursprüngliche Problem, das man einen JInternalFrame kein zweites mal öffnen konnte habe ich so lösen können. Nur habe ich dadurch das eigentlich Problem besser erkennen können. Denn nachdem das Objekt einmal instanziert wurde behält es der GC auch wenn ich ihn dazu "ermutige" es zu löschen. Das äußert sich folgendermaßen:

Beim erneuten aufruf des Frames wird weder der Konstruktor aufgerufen noch das Ereignis internalFrameOpened ausgelöst. Ok man mag denken das man die 2-3Mb Speicher heutzutage ja über hat. Aber ich schreibe gerade an einem Datenbank Frontend nehmen wir mal folgenden Fall an: Der Benutzer öffnet ein Formular und sieht darin einige Daten aus der Datenbank. So nun schliesst er das Formular, beendet aber nicht das ganze Programm. Zwischenzeitlich ändert jemand anderes einige Datensätze in der Datenbank. Der Benutzer maximiert das Programm und öffnet erneut das gleiche Formular und sieht nun die veralteten Daten da das Objekt nicht neu angelegt wurde.

Grüsse
Spontex

 

[Beni]

Du verstehst nicht, was der GarbageCollector macht, bzw. du hast dein Programm nicht so aufgebaut, dass der GC überhaupt was machen müsste.

Der GC vernichtet Objekte, auf die es keine einzige Referenz mehr gibt.

Aber du besitzt immer eine Variable die auf ein Frame zeigt:

public class CTestFrame2 extends JInternalFrame{

   private static CTestFrame2 m_Frame;  // Die Referenz auf ein TestFrame
   
   private CTestFrame2() {
      ..
   }
   
   public static synchronized CTestFrame2 getInstance() {
      // zeigt die Variable m_Frame bereits auf ein Objekt, wird nichts gemacht.
      // ansonsten wird die Variable auf ein neues Objekt gesetzt
      if (m_Frame == null) {
         m_Frame = new CTestFrame2();
      }
      return m_Frame;
   }
}

Es gibt niergends eine Codestelle die die Variable m_Test wieder auf null (oder ein anderes Objekt) zeigen lässt -> sie zeigt immer auf dasselbe Objekt (welches dadurch niemals vom GC gelöscht wird).

(Variablen die mit "static" gekennzeichnet sind, haben die Eigenschaft, dass sie nie "verloren" gehen, so wie etwa lokale Variablen in einer Methode. Deshalb hat der GC auch nie einen Grund das Frame zu vernichten, du musst die Variable m_Frame explizit auf null setzen...)

Beim wechsel des LookAndFeels könntest du auch die Methode SwingUtilities.updateComponentTreeUI aufrufen, und der Methode die Frames übergeben, das wäre wahrscheinlich sinnvoller als löschen.

 

[Spontex]

Wie eine zeile code doch die Welt verändern kann:

m_Frame = null;

Ich sollte weniger zwischen C++, Vb und Java hin- und herspringen - ich hoffe ihr lasst mir das durchgehen :wink:

 

[Beni]

Wollen wir mal so freundlich sein

Aber du musst dir bewusst sein, dass "finalize" nicht unbedingt aufgerufen wird, und auch der Zeitpunkt wann das geschieht nicht sicher ist.

Ich empfehle Dir eine Methode zu schreiben, welche so eine Art Pseudo-Dekonstruktor ist. Diese Methode rufst du dann selbst auf, und dann kannst du sicher sein, dass die Variablen korrekt gesetzt werden :wink:

 

[Spontex]

Wollen wir mal so freundlich sein

Aber du musst dir bewusst sein, dass "finalize" nicht unbedingt aufgerufen wird, und auch der Zeitpunkt wann das geschieht nicht sicher ist.

Ich empfehle Dir eine Methode zu schreiben, welche so eine Art Pseudo-Dekonstruktor ist. Diese Methode rufst du dann selbst auf, und dann kannst du sicher sein, dass die Variablen korrekt gesetzt werden :wink:

Als Pseudo De- Konstruktor benutze ich jetzt die Ereignisse internalFrameOpened und internalFrameClosed, klappt wunderbar. Nur wie ist das denn bei bei einer "normalen" Klasse und finalize(). z.B. meine Klasse welche die Verbindung zur Datenbank herstellt - dort prüfe ich in finalize() ab ob noch eine Verbindung zur DB besteht, falls ja soll diese natürlich beendet werden. Das scheint auch zu funktionieren, denn ansonsten würde ich ja übrig geliebene Verbindungen auf dem MySQL Server sehen. Wobei ich die Klasse auch nur entlade wenn ich das Programm beende - kann ich dort davon ausgehen das finalize() aufgerufen wird oder gibt es vielleicht eine sicherere Möglichkeit das Programmende zu erkennen und dann die DB Verbindung zu trennen?

Grüsse
Spontex

 

[Beni]

Also soweit ich das weiss, kannst du nicht 100% sicher sein, wenn du finalize dafür verwendest.

Aber wer beendet denn das Programm?

Falls es einfach durch das schliessende Frame beendet wird: füg dem Frame einen WindowListener hinzu, und reagiere entsprechend (Verbindungen löschen), wenn windowClosing aufgerufen wird :wink: