Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / May 2007

Tip: Looking for answers? Try searching our database.

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

Thread view: 
Jack Dowson - 12 May 2007 17:13 GMT
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 - 12 May 2007 17:28 GMT
> Hello Everybody:
> As we all know,System.exit(0) is often used to quit the program.
[quoted text clipped - 7 lines]
> 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.

Signature

Daniel Dyer
https://watchmaker.dev.java.net - Evolutionary Algorithm Framework for Java

Jack Dowson - 12 May 2007 18:26 GMT
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.
Daniel Dyer - 12 May 2007 18:33 GMT
> Daniel Dyer 写道:
>> It's better to do it this way:
[quoted text clipped - 4 lines]
>
> 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.

Signature

Daniel Dyer
https://watchmaker.dev.java.net - Evolutionary Algorithm Framework for Java

Jack Dowson - 12 May 2007 18:45 GMT
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 - 12 May 2007 18:54 GMT
> Daniel Dyer 写道:
>
[quoted text clipped - 14 lines]
>      }
> }

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.

Signature

Daniel Dyer
https://watchmaker.dev.java.net - Evolutionary Algorithm Framework for Java

Joshua Cranmer - 12 May 2007 17:49 GMT
> Hello Everybody:
> As we all know,System.exit(0) is often used to quit the program.
[quoted text clipped - 16 lines]
> 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 - 12 May 2007 17:54 GMT
...
>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

Signature

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

Daniel Dyer - 12 May 2007 18:14 GMT
> ..
>> As we all know,System.exit(0) is often used to quit the program.
[quoted text clipped - 7 lines]
> 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.

Signature

Daniel Dyer
https://watchmaker.dev.java.net - Evolutionary Algorithm Framework for Java

Stefan Ram - 12 May 2007 18:31 GMT
>It's worth mentioning the @Override annotation in this context.

 This can be used when extending classes,
 but not when implementing interfaces.
Daniel Dyer - 12 May 2007 18:33 GMT
>> It's worth mentioning the @Override annotation in this context.
>
>   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.

Signature

Daniel Dyer
https://watchmaker.dev.java.net - Evolutionary Algorithm Framework for Java

Ingo R. Homann - 14 May 2007 13:19 GMT
Hi Stefan,

>>It's worth mentioning the @Override annotation in this context.
>
>   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 - 14 May 2007 18:01 GMT
>>>It's worth mentioning the @Override annotation in this context.
>>   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).

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.
--
Mark Rafn    dagon@dagon.net    <http://www.dagon.net/>
Ingo R. Homann - 15 May 2007 08:38 GMT
Hi,

>>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.

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
Jack Dowson - 12 May 2007 18:37 GMT
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>
[quoted text clipped - 29 lines]
> }
> </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.
Andrew Thompson - 12 May 2007 19:19 GMT
(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.

Signature

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

Jack Dowson - 12 May 2007 19:23 GMT
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 - 12 May 2007 19:30 GMT
>Andrew Thompson 写道:
>> The 'former condition' would be meaning what?
[quoted text clipped - 3 lines]
>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.  ;-)

Signature

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



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.