JDK-4688142 : REGRESSION: case where opening a modal dialog will hang the application.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-05-20
  • Updated: 2002-08-22
  • Resolved: 2002-08-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
Description

Name: gm110360			Date: 05/20/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]
ServicePack 2

A DESCRIPTION OF THE PROBLEM :
This bug is very closely related to bug #4636311 but is a
more generic way of recreating the problem.  Basicaly, I
have found a way to consistantly hang the application just
by opening a modal dialog a specific time.  In my test
program that I provided, I am opening a modal dialog from
the windowActivated(...) event of a window listener of a
JFrame.  This will effectively open the dialog right after
the frame becomes visible.  This will hang the VM every
time.  This bug is EXTREMELY detrimental to our
application, as there are several places where we open
dialogs at various times as windows are opened, or as they
are activated to do auto-processing and such.  This problem
makes those features completely unusable.  I have seen
proposed work-arounds that involve pushing the open to a
SwingUtilities.invokeLater(...), but this really isn't a
viable option as it would involve massive restructuring of
evey place this could possibly get hit in order to allow
the setVisible(true) to be pushed into a runnable that can
be invoked later and still maintain the fact that it needs
to be modal.  Please give us some resolution to this issue.

REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Run the sample code.
2.When the frame and the dialog appear, the app. will be
locked.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Both the frame and the dialog should open without issue.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class Example
{
    public static void main(String [] args)
    {
        final JFrame f = new JFrame();
        f.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        
        f.getContentPane().add(new JLabel("Parent Frame"));
        f.addWindowListener(new WindowAdapter(){
            public void windowActivated(WindowEvent e)
            {
                JDialog d = new JDialog(f, "Modal Dialg", true);
                d.getContentPane().add(new JLabel("Child Dialog"));
                d.pack();
                d.setVisible(true);
            }
        });
        f.pack();
        f.setVisible(true);
    }
}
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
None known.
(Review ID: 146807) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis
24-08-2004

EVALUATION Commit to fix in mantis. ###@###.### 2002-05-23 Name: osR10079 Date: 08/02/2002 The problem is the same as 4531693 ======================================================================
23-05-2002