Bug ID: JDK-4515058 application does not exit after printing

JDK-4515058 : application does not exit after printing

Details

Type:	Bug	Submit Date:	2001-10-16
Status:	Closed	Updated Date:	2002-06-12
Project Name:	JDK	Resolved Date:	2002-04-18
Component:	client-libs	OS:	solaris_8
Sub-Component:	java.awt:i18n	CPU:	sparc
Priority:	P4
Resolution:	Won't Fix
Affected Versions:	1.4.0
Fixed Versions:

Related Reports

Relates:	JDK-4844504 - PIT: printing application does not exit
Relates:	JDK-4670707 - Need for daemon property on AWT components
Relates:	JDK-4671025 - Java input methods should not prevent AWT from auto shutdown

Sub Tasks

Description

An application does not exit after printing is completed. This bug is occuring in merlin build 82 in solaris 8. It can be seen in the attached program. 

How to reproduce the bug :

Compile and run the program. Close the program without doing anything. The program will exit cleanly. Now, run the application again and click on the print button. Click on the print button of the printdialog that comes up. Close the window. The frame gets closed but the application does not exit back to the command prompt.

import java.awt.*;
import java.awt.event.*;
import java.awt.print.*;

public class MultiplePrinting implements ActionListener{

        final Frame TstFrm = new Frame("Test Frame");
        Button PrnBtn = new Button("Print");

        public static void main(String []args){
                MultiplePrinting Mtp = new MultiplePrinting();
        }

        public MultiplePrinting(){
                TstFrm.addWindowListener(new WindowAdapter(){
                        public void windowClosing(WindowEvent we){
                                TstFrm.dispose();
                        }
                });
                PrnBtn.addActionListener(this);
                TstFrm.add(PrnBtn,BorderLayout.SOUTH);
                TstFrm.setSize(100,100);
                TstFrm.setVisible(true);
        }

        public void actionPerformed(ActionEvent ae){
                JobAttributes JbAtrb = new JobAttributes();
                JbAtrb.setCopies(2);
                JbAtrb.setDialog(JobAttributes.DialogType.NATIVE);
                PrintJob PJ = Toolkit.getDefaultToolkit().getPrintJob(
                        TstFrm,"Testing Multiple", JbAtrb,null);
                if (PJ != null){
                        Graphics G = PJ.getGraphics();
                        if (G != null){
                                G.setFont(new Font("Dialog", Font.BOLD, 16));
                                G.setColor(Color.black);
                                G.drawString("Page 1" , 100, 40);
                        }
                        G.dispose();
                }
                PJ.end();
                PJ = null;
        }

}


###@###.### 2001-10-16
I have inadvertently put the build as 82. The bug is reproducible in build 83 as well

Comments

WORK AROUND

        public MultiplePrinting(){
                TstFrm.addWindowListener(new WindowAdapter(){
                        public void windowClosing(WindowEvent we){
                                TstFrm.dispose();
                                System.exit(0);    // force application exit
                        }
                });

2004-06-11

EVALUATION

Work-around provided.
###@###.### 2001-10-16

This is possibly not a bug; it is certainly not a regression, since it happens in 1.3.1.  I am passing it on to 2D to evaluate further.
###@###.### 2001-11-06

This has nothing to do with 2D and it isn't a bug.  If you comment out all of
the code inside of actionPerformed (so that it does not call PrintJob at all),
it still doesn't exit.  The event thread is still going to be around.  The
user must explicitly call System.exit() if he/she wishes to stop an AWT app.
This is probably a dup of another AWT bug.  I will let AWT close it.
###@###.### 2001-11-07

Name: dsR10078			Date: 11/08/2001



The application doesn't exit as showing print dialog causes
the input method composition window to be shown. Here is the stack
trace indicating the point where the peer is created:

        at java.awt.Frame.addNotify(Frame.java:472)
        at java.awt.Window.pack(Window.java:416)
        at sun.awt.im.CompositionArea.<init>(CompositionArea.java:74)
        at sun.awt.im.CompositionAreaHandler.<init>(CompositionAreaHandler.java:53)
        at sun.awt.im.InputMethodContext.getCompositionAreaHandler(InputMethodContext.java:196)
        at sun.awt.im.InputMethodContext.dispatchEvent(InputMethodContext.java:178)
        at java.awt.Component.dispatchEventImpl(Component.java:3477)
        at java.awt.Container.dispatchEventImpl(Container.java:1440)
        at java.awt.Component.dispatchEvent(Component.java:3368)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:193)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:147)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:137)
        at java.awt.Dialog.show(Dialog.java:527)
        at java.awt.Component.show(Component.java:1131)
        at java.awt.Component.setVisible(Component.java:1086)
        at sun.awt.print.PrintDialog.display(PrintDialog.java:520)
        at sun.awt.print.PrintControl.displayCommonDialog(PrintControl.java:462)
        at sun.awt.print.PrintControl.displayNativeDialog(PrintControl.java:511)
        at sun.awt.print.PrintControl.displayDialog(PrintControl.java:418)
        at sun.print.PrintJob2D.printDialog(PrintJob2D.java:160)
        at sun.awt.motif.MToolkit.getPrintJob(MToolkit.java:418)
        at MultiplePrinting.actionPerformed(MultiplePrinting.java:30)
        at java.awt.Button.processActionEvent(Button.java:384)
        at java.awt.Button.processEvent(Button.java:353)
        at java.awt.Component.dispatchEventImpl(Component.java:3527)
        at java.awt.Component.dispatchEvent(Component.java:3368)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:193)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:147)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:141)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:133)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:101)

The AWT will not shutdown until all peers are disposed. 
The input method composition window is never disposed, so AWT never
shuts down and the application never exits.

###@###.### 2001-11-08

====================================================================== 

This problem seems to have broken the fix for 4030718.  We ought to address 
it as soon as we can.  
###@###.### 2001-11-08

No, 4030718 isn't broken.  I spent a little while chasing this.  First of all, 
I wasn't able to reproduce it on WindowsNT with merlin build 86 (the latest).  
Second, I was able to reproduce it on sparc all the way back to merlin-beta build 64 - the oldest one I could find.  So, it doesn't appear to be a 
regression of any kind.  We should still try to fix it in an upcoming release, 
though.  
###@###.### 2001-11-15

======================================================================

Changed the composition area code to delay the creation of the window until it is actually required to get shown.  So no peer is recorded in the map in this case.

###@###.### 2001-11-19

======================================================================

The problem does not happen with the change above for the host input method, but there still is the problem if the user uses the Java input method.  Changed back to the committed state.

###@###.### 2001-11-19

After a long discussion with Danila, we have agreed to close this bug as "will not fix", as there is no complete way to fix this problem without changing AWT and IMF specs.  Two new RFEs are filed against AWT (4670707) and IMF (4671025).  Please see Comments section for the entire email discussion.

###@###.### 2002-04-18

2002-04-18

SUGGESTED FIX



Name: dsR10078			Date: 11/09/2001



Currently the peer for the composition window is created as soon as
the window itself is created and it is never disposed.
A possible fix could be to ensure that the composition window has 
a peer when and only when it is visible on screen. The peer should 
be created just before the composition window needs to be shown. 
The composition window should be disposed when it gets hidden.

###@###.### 2001-11-08

======================================================================

2001-11-08

SELECT A COUNTRY/REGION
Africa Operation Argentina Australia Austria Bahrain Bangladesh Belgium & Luxembourg Belize Bhutan Bolivia Bosnia & Herzegovina Brasil Brunei Bulgaria Cambodia Canada - English Canada - French Chile China Colombia	Costa Rica Croatia Cyprus Czech Republic Denmark Ecuador Egypt Estonia Finland France Germany Greece Guatemala Honduras Hong Kong Hungary India Indonesia Iraq Ireland	Israel Italy Japan Jordan Kazakhstan Korea Kuwait Laos Latvia Lebanon Lithuania Malaysia Maldives Malta Mexico Moldova Nepal Netherlands New Zealand Nicaragua	Norway Oman Pakistan Panama Paraguay Peru Philippines Poland Portugal Puerto Rico Qatar Romania Russia Saudi Arabia Serbia & Montenegro Singapore Slovakia Slovenia South Africa Spain	Sri Lanka Sweden Switzerland -- French Switzerland -- German Taiwan Thailand Turkey Ukraine United Arab Emirates United Kingdom United States Uruguay Venezuela Vietnam Yemen

Hardware and Software, Engineered to Work Together