Query:the real function of System.exit(0)?

[Jack Dowson]

Hello Everybody:
As we all know,System.exit(0) is often used to quit the program.
But when it applied to some of my programs,the outcome was not so.
I created a frame using class JFrame.Then I registerd WindowsAdapter on
the close action,and here came the problem:
When I only used System.exit(0) in the rewrote of method
windowClosing,it cloud never close the window normally.(I could only use
ctrl+c or more often directly kill the process to end this)
But when I added frame.dispose() before it,then it worked well,
here frame is an instance created by JFrame.If the sentence
frame.dispose() came after System.exit(0),neither would it do the job.


Why?
My os is WindowsXP,and jdk version is(created by command java -version):
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)


Any help will be greatly appreciated!
Dowson.

 

[Daniel Dyer]

Hello Everybody:
As we all know,System.exit(0) is often used to quit the program.
But when it applied to some of my programs,the outcome was not so.
I created a frame using class JFrame.Then I registerd WindowsAdapter on
the close action,and here came the problem:
When I only used System.exit(0) in the rewrote of method
windowClosing,it cloud never close the window normally.(I could only use
ctrl+c or more often directly kill the process to end this)
But when I added frame.dispose() before it,then it worked well,
here frame is an instance created by JFrame.If the sentence
frame.dispose() came after System.exit(0),neither would it do the job.

It's better to do it this way:

myFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

Dan.

 

[Joshua Cranmer]

Hello Everybody:
As we all know,System.exit(0) is often used to quit the program.
But when it applied to some of my programs,the outcome was not so.
I created a frame using class JFrame.Then I registerd WindowsAdapter on
the close action,and here came the problem:
When I only used System.exit(0) in the rewrote of method
windowClosing,it cloud never close the window normally.(I could only use
ctrl+c or more often directly kill the process to end this)
But when I added frame.dispose() before it,then it worked well,
here frame is an instance created by JFrame.If the sentence
frame.dispose() came after System.exit(0),neither would it do the job.


Why?
My os is WindowsXP,and jdk version is(created by command java -version):
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)


Any help will be greatly appreciated!
Dowson.

System.exit(0) /immediately/ terminates the VM. In fact, (qtd. from the
Java API) "[this] method never terminates normally."

windowClosing is called before the window is closed, so when you exited
from windowClosing, the VM couldn't close the window.

If you want to exit when the window is closed, use JFrame's
setDefaultCloseOperation.

 

[Andrew Thompson]

Jack Dowson wrote:
...

As we all know,System.exit(0) is often used to quit the program.
But when it applied to some of my programs,the outcome was not so.
I created a frame using class JFrame.Then I registerd WindowsAdapter

That is most probably the problem. If you spelt the
method name incorrectly, or using wrong arguments
using a WindowAdapter gives no complaint at compile
time, and no effect at runtime. Try implementing a
WindowListener instead - that forces you to implement
the correct methods.

See if this example works for you..
<sscce>
import java.awt.event.*;
//import java.awt.Frame;
import javax.swing.JFrame;

class CloseWindow {

public static void main(String[] args) {
//Frame f = new Frame("Close Me!");
JFrame f = new JFrame("Close Me!");

f.addWindowListener( new WindowListener(){
public void windowDeactivated(WindowEvent we) {}
public void windowActivated(WindowEvent we) {}

public void windowDeiconified(WindowEvent we) {}
public void windowIconified(WindowEvent we) {}

public void windowOpened(WindowEvent we) {}
public void windowClosed(WindowEvent we) {}
public void windowClosing(WindowEvent we) {
System.out.println(we);
System.exit(0);
}
} );

f.setSize(200,100);
f.setLocation(50,50);
f.setVisible(true);
}
}
</sscce>

Note that for Swing based JFrames, I would heed
Daniel's advice to use defaultCloseOperation(),
but adding a WindowListener works, and does
so for both Swing and AWT based components.
In fact, uncomment the two commented lines,
and comment the two lines following them, and
you might see the same effect on an AWT Frame.

HTH

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200705/1

 

[Daniel Dyer]

Jack Dowson wrote:
..

That is most probably the problem. If you spelt the
method name incorrectly, or using wrong arguments
using a WindowAdapter gives no complaint at compile
time, and no effect at runtime. Try implementing a
WindowListener instead - that forces you to implement
the correct methods.

It's worth mentioning the @Override annotation in this context. It's
supposed to help you catch these situations by telling the compiler that
you intended to over-ride a method. Of course, you still have to remember
to add the annotation...

Dan.

 

[Jack Dowson]

Daniel Dyer 写é“:

It's better to do it this way:

myFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

Dan.

Thank you very much!

I've tried,but it did not work either.

 

[Stefan Ram]

It's worth mentioning the @Override annotation in this context.

This can be used when extending classes,
but not when implementing interfaces.

 

[Daniel Dyer]

This can be used when extending classes,
but not when implementing interfaces.

I was referring to extending WindowAdapter in preference to implementing
WindowListener directly.

Dan.

 

[Daniel Dyer]

Daniel Dyer 写é“:
Thank you very much!

I've tried,but it did not work either.

That's odd. Do you still have a WindowListener doing something? Probably
need to see the code at this point?

Dan.

 

[Jack Dowson]

Thank you so much for helping me again,Andrew.

That is most probably the problem. If you spelt the
method name incorrectly, or using wrong arguments
using a WindowAdapter gives no complaint at compile
time, and no effect at runtime. Try implementing a
WindowListener instead - that forces you to implement
the correct methods.

I've checked every word I spelled,and found nothing wrong.

See if this example works for you..
<sscce>
import java.awt.event.*;
//import java.awt.Frame;
import javax.swing.JFrame;

class CloseWindow {

public static void main(String[] args) {
//Frame f = new Frame("Close Me!");
JFrame f = new JFrame("Close Me!");

f.addWindowListener( new WindowListener(){
public void windowDeactivated(WindowEvent we) {}
public void windowActivated(WindowEvent we) {}

public void windowDeiconified(WindowEvent we) {}
public void windowIconified(WindowEvent we) {}

public void windowOpened(WindowEvent we) {}
public void windowClosed(WindowEvent we) {}
public void windowClosing(WindowEvent we) {
System.out.println(we);
System.exit(0);
}
} );

f.setSize(200,100);
f.setLocation(50,50);
f.setVisible(true);
}
}
</sscce>

I've tried,and the system replied:
java.awt.event.WindowEvent[WINDOW_CLOSING,opposite=null,oldState=0,newState=0]
on frame0
and then went back to the former condition.
It was the same result when I uncommented the two commented lines and
commented the two lines following them.
Why?

Dowson.

 

[Jack Dowson]

Daniel Dyer 写é“:

That's odd. Do you still have a WindowListener doing something?
Probably need to see the code at this point?

Dan.

Thank you,Dan.
That's my simple code:
import javax.swing.*;
public class CloseWindow{
public static void main(String[] args){
JFrame frame = new JFrame("Close");
frame.setSize(300,300);
frame.setLocation(100,100);
frame.setVisible(true);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
}

 

[Daniel Dyer]

Daniel Dyer 写é“:

That's odd. Do you still have a WindowListener doing something?
Probably need to see the code at this point?
Dan.

Thank you,Dan.
That's my simple code:
import javax.swing.*;
public class CloseWindow{
public static void main(String[] args){
JFrame frame = new JFrame("Close");
frame.setSize(300,300);
frame.setLocation(100,100);
frame.setVisible(true);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
}

Works exactly as expected for me (MacOS X, JDK 1.5.0_07).

I can only guess that there is a bug in that specific version of the JRE
that you are using, or something odd with your machine. It might be worth
trying a later build.

Dan.

 

[Andrew Thompson]

Jack Dowson wrote:

(example code)

I've tried,and the system replied:
java.awt.event.WindowEvent[WINDOW_CLOSING,opposite=null,oldState=0,newState=0]
on frame0
and then went back to the former condition.

The 'former condition' would be meaning what?
a) The frame, on screen and visible.
b) The screen, no frame (frame exits).

Why?

Here, it was 'b' for both Frame and JFrame.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200705/1

 

[Jack Dowson]

Andrew Thompson 写é“:

The 'former condition' would be meaning what?
a) The frame, on screen and visible.
b) The screen, no frame (frame exits).

Thank you.
It was a) for meï¼
The frame is on screen and visible,only by kill the process can I end
the program.

Dowson.

 

[Andrew Thompson]

Andrew Thompson 写é“:

Thank you.
It was a) for meï¼

That is unfortunate! That is the first time I have
heard that not work to exit the VM and *close*
the frame.

The frame is on screen and visible,only by kill the process can I end
the program.

Huhh.. best stick with Swing and setDefaultCloseOperation(),
then. ;-)

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200705/1

 

[Ingo R. Homann]

Hi Stefan,

This can be used when extending classes,
but not when implementing interfaces.

The reason is that it is not necessary when implementing an interface
because the compiler will warn you as well, when you misspell the method
name (although the error is slightly different "class x must be declared
abstract or implement method y" or somehthing like that).

Ciao,
Ingo

 

[Mark Rafn]

It's worth mentioning the @Override annotation in this context.

The reason is that it is not necessary when implementing an interface
because the compiler will warn you as well, when you misspell the method
name (although the error is slightly different "class x must be declared
abstract or implement method y" or somehthing like that).

Unless it's a method that's accidentally provided by some parent class. Or
unless it's a method you think is on the interface and it's not. It
would be nice if @Override worked for interface methods, or if there were an
@Implement annotation to provide similar safety for interfaces.

 

[Ingo R. Homann]

Hi,

Unless it's a method that's accidentally provided by some parent class.

Then you will have problems in any case!

> Or
unless it's a method you think is on the interface and it's not.

No, because, then the method on the interface is not implemented at all
and the compiler will warn you!

> It
would be nice if @Override worked for interface methods, or if there were an
@Implement annotation to provide similar safety for interfaces.

ACK to this.

Ciao,
Ingo