JDK-4291432 : Program does not return the command prompt
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: generic
  • CPU: generic
  • Submitted: 1999-11-15
  • Updated: 2000-05-19
  • Resolved: 2000-05-19
Related Reports
Relates :  
Description

Name: skC96842			Date: 11/15/99



When I instantiate a Frame(Example:..Frame f=new Frame()) and run it,JVM
exits
in 1.3.0.J build but in 1.3.0.N build the JVM does not exit.
( Tested in Windows platform )

//////////Testcase begin

import java.awt.*;

public class test{

public static void main(String[] arg){

 Frame f = new Frame();
}

}

/////////// Testcase end
======================================================================

Name: krT82822			Date: 01/21/2000


1/21/2000 eval1127@eng -- duping this to 4291432, the closest relative that is in "committed" state.

java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)

A simple Java program that displays a JOptionPane does not terminate when the
main function has exited and the option pane dismissed. I.e., there are no open
Swing windows and no non-daemon threads, but the virtual machine doesn't
terminate.

-------------------------------------

1/20/2000 mail back from user, in reply to suggestion that System.exit() be used (to treminate the "simple Java program"):

That's not what the docs and the Java Tutorial say. On the contrary, they 
suggest developers avoid System.exit() like the plague in case the program 
is run from a bigger context, like a Java written application launcher or 
shell or a Java operating system. They state that when there are no windows 
open and no non-daemon threads running the VM will terminate.

I say this is a bug. I seem to recall seeing a similar bug on the Bug Parade 
once -- a problem with programs that used an AWT window not terminating. It 
seems that the problem has been copied over to or inherited in Swing.

Q.v. bugs #4030718, 4038690, 4072987, 4125114, 4152761,

Note on bug #4030718:
* is the original report with the AWT window and program not
  terminating
* has nearly 200 votes!
* is marked as being "in progress, bug" -- meaning someone in your
  engineering department decided this behavior of the AWT is incorrect
  -- so the similar problem I'm observing in Swing is, by this
  precedent, also a bug, and probably has the same cause too.

Note on bug #4072987:
* It is remarked upon that having to use System.exit() isn't clean
  in complex deployment situations, and this is accepted by the
  engineer respondent.

Furthermore, the 100% Pure Java Certification Guide 
(http://web2.java.sun.com/100percent/cert_guide.html) contains the following 
remark about the use of System.exit():

Pitfall: Misuse of System.exit

Explanation: The System.exit method forces termination of all
threads in the Java virtual machine. This is drastic. It might, for
example, destroy all windows created by the interpreter without giving
the user a chance to record or even read their contents.

Solution: Applications should usually terminate by stopping all non-daemon
threads; in the simplest case of a command-line application, this is as easy 
as returning from the main method. System.exit should be reserved for a
catastrophic error exit, or for cases when a application is intended for use 
as a utility in a command script that may depend on the application?s exit code.
(Review ID: 100190)
======================================================================

Comments
WORK AROUND Name: krT82822 Date: 01/21/2000 You have to write code to detect these conditions manually and invoke System.exit(), even though this is considered bad practise, as the program might be running in a larger Java context, such as a Java OS, in the future. Alternatively, the user can terminate the process forcibly, by e.g. hitting ^C in the command prompt window under Windows. (Review ID: 100190) ======================================================================
11-06-2004

EVALUATION This is caused by changes Thanh made to Window(GraphicsConfiguration). If the portions of Window(GraphicsConfiguration) relating to GraphicsConfigurations are commented out, we return to the old behavior. Window(GraphicsConfiguration gc) { setWarningString(); this.cursor = Cursor.getPredefinedCursor(Cursor.DEFAULT_CURSOR); this.focusMgr = new FocusManager(this); this.visible = false; /* if (gc == null) { this.graphicsConfig = GraphicsEnvironment.getLocalGraphicsEnvironment(). getDefaultScreenDevice().getDefaultConfiguration(); } else { this.graphicsConfig = gc; } if (graphicsConfig.getDevice().getType() != GraphicsDevice.TYPE_RASTER_SCREEN) { throw new IllegalArgumentException("not a screen device"); } */ setLayout(new BorderLayout()); /* offset the initial location with the original of the screen */ /* Rectangle screenBounds = graphicsConfig.getBounds(); int x = getX() + screenBounds.x; int y = getY() + screenBounds.y; setLocation(x, y); */ } I spoke with Thanh and he said he thinks we can allow a null grpahicsConfig variable, but that such a change has moderate risk. A more thorough analysis is required. david.mendenhall@eng 1999-11-15 This is essentially the same problem as the RFE: 4030718. We intend to fix this in Merlin, along with 4030718. eric.hawkes@eng 2000-03-08 This bug is not reproducible in Merlin. Below is the result of the investigation by the responsible engineer: ###@###.### This bug doesn't exist on merlin builds available at our end (b11-b14) although it is reproducible on win32 with the latest kestrel build 1.3.0-C The stack trace which indicates the point of the toolkit initialization for that build is as follows: [1] java.awt.Toolkit.getDefaultToolkit (Toolkit:482) [2] sun.awt.GlobalCursorManager$CursorEvent.<init> (GlobalCursorManager$CursorEvent:28) [3] sun.awt.GlobalCursorManager.<clinit> (GlobalCursorManager:65) [4] java.awt.Cursor.initIDs (native method) [5] java.awt.Cursor.<clinit> (Cursor:171) [6] java.awt.Window.<init> (Window:182) [7] java.awt.Frame.<init> (Frame:315) [8] java.awt.Frame.<init> (Frame:262) [9] Test.main (Test:6) This chain was removed with the fix for 4281631. Closing as Not Reproducible. eric.hawkes@eng 2000-05-19
19-05-2000