Misc
Java - Swing Window Closing
Swing Application JFrame - in case of a "windowClosing": if you forgot to implement a WindowListener to react in a correct way (eg. with System.exit), you notice no unusual behaviour, the Window closes but Resources are not deallocated. finally this "memory leak" leads to a blue screen because of massive memory allocation (on my W2000 PC). Default behaviour on a JFrame-windowclose is to hide the Frame (HIDE_ON_CLOSE), but no deallocation takes place - the VM is still running.
There are several options for an application to exit, when you set DISPOSE_ON_CLOSE or EXIT_ON_CLOSE the window (jframe) and VM terminates in case of a window closing event. (Whether a Windowlistener which reacts on a windowclosing event is present or not).
But it is usual to confirm a program exit. I noticed two ways for this:
- set setDefaultCloseOperation(DO_NOTHING_ON_CLOSE) for your frame and implement a windowlistener. within you can popup a confirmation dialog an do a system.exit or dispose() call
- set DISPOSE_ON_CLOSE and instead of writing a windowlistener overwrite dispose(). if an exit is required a call to super.dispose() does dispose all child components and terminates the VM - when there are no more active threads.
a dispose call only terminates the vm if no other window is displayable.
a VM-terminating system.exit call is not suitable if your application is used as an embedded component (e.g. a subprogram in its own window). if this is the case you have to work with dispose() for closing your subapplication. As the main app is still active, dispose does not terminate the VM and leaves your disposed frame in an usable state. a pack() and show() call restarts your subapplication.
sometimes a dispose call does not terminate the vm in spite of your application is the only one. check out if there are no more active threads. if this is ok, maybe you used an JOptionPane without setting the parent component. if this is the case, then the vm may not terminate !
VM terminates:
public void dispose() {
int n = JOptionPane.showOptionDialog(this,...
super.dispose();
}
VM does NOT terminate:
public void dispose() {
int n = JOptionPane.showOptionDialog(null,...
super.dispose();
}
Java - Jakarta Commons CLI.
If you use a PosixParser, you are safe when using only single char options. When you are using "longopts" the api allows a recognition, but argument value retrieval delivers not accurate. e.g. for "-outputdir temp" you get "utputdir temp". As a rule of thumb, longopt-options without arguments are quite usable, without arguments its better to use the default (short) single-char-option.
Swing Application JFrame - in case of a "windowClosing": if you forgot to implement a WindowListener to react in a correct way (eg. with System.exit), you notice no unusual behaviour, the Window closes but Resources are not deallocated. finally this "memory leak" leads to a blue screen because of massive memory allocation (on my W2000 PC). Default behaviour on a JFrame-windowclose is to hide the Frame (HIDE_ON_CLOSE), but no deallocation takes place - the VM is still running.
There are several options for an application to exit, when you set DISPOSE_ON_CLOSE or EXIT_ON_CLOSE the window (jframe) and VM terminates in case of a window closing event. (Whether a Windowlistener which reacts on a windowclosing event is present or not).
But it is usual to confirm a program exit. I noticed two ways for this:
- set setDefaultCloseOperation(DO_NOTHING_ON_CLOSE) for your frame and implement a windowlistener. within you can popup a confirmation dialog an do a system.exit or dispose() call
- set DISPOSE_ON_CLOSE and instead of writing a windowlistener overwrite dispose(). if an exit is required a call to super.dispose() does dispose all child components and terminates the VM - when there are no more active threads.
a dispose call only terminates the vm if no other window is displayable.
a VM-terminating system.exit call is not suitable if your application is used as an embedded component (e.g. a subprogram in its own window). if this is the case you have to work with dispose() for closing your subapplication. As the main app is still active, dispose does not terminate the VM and leaves your disposed frame in an usable state. a pack() and show() call restarts your subapplication.
sometimes a dispose call does not terminate the vm in spite of your application is the only one. check out if there are no more active threads. if this is ok, maybe you used an JOptionPane without setting the parent component. if this is the case, then the vm may not terminate !
VM terminates:
public void dispose() {
int n = JOptionPane.showOptionDialog(this,...
super.dispose();
}
VM does NOT terminate:
public void dispose() {
int n = JOptionPane.showOptionDialog(null,...
super.dispose();
}
Java - Jakarta Commons CLI.
If you use a PosixParser, you are safe when using only single char options. When you are using "longopts" the api allows a recognition, but argument value retrieval delivers not accurate. e.g. for "-outputdir temp" you get "utputdir temp". As a rule of thumb, longopt-options without arguments are quite usable, without arguments its better to use the default (short) single-char-option.
