In Unix, main JFrame focus not regained after modal dialog exit.

Question

Hi all,
I'm new to this forum so hopefully this is the right place to put this question.
I have a relatively simple GUI application written in Java 6u20 that involves a main gui window (extends JFrame). Most of the file menu operations result in a modal dialog (either JFileChooser or JOptionPane) being presented to the user.
The problem is that when running on Unix (HPUX), the process of changing focus to one of these modal dialogs occasionally results in a quick flash of the background terminal window (not necessarily that used to launch the Java), and the process of closing the modal dialogs (by any means, i.e. any dialog button or hitting esc) doesn't always return focus to the main extended JFrame object, sometimes it goes to the terminal window and sometimes just flashes the terminal window before returning to the main JFrame window.
I think the problem is with the Unix window manager deciding that the main focus should be a terminal window, not my Java application, since the problem occurs in both directions (i.e. focus from main JFrame to modal dialog or vice versa).
In most cases of JOptionPane, I DO specify that the main extended JFrame object is the parent.
I've tried multiple things since the problem first occured, including multiple calls to a method which calls the following:
.toFront();
.requestFocus();
.setAlwaysOnTop(true);
.setVisible(true);
..on the main JFrame window (referred to as a public static object)...
just before and after dialog display, and following selection of any button from the dialogs. This reduced the frequency of the problem, but it always tends to flash the terminal window if not return focus to it completely, and when it occurs (or starts to occur then gets worse) is apparently random! (which makes me think it's an OS issue)
Any help appreciated thanks,
Simon
Self-contained compilable example below which has the same behaviour, but note that the problem DOESN'T occur running on Windows (XP) and that my actual program doesn't use auto-generated code generated by a guibuilder:
* To change this template, choose Tools | Templates 
* and open the template in the editor. 
package example;  
import javax.swing.JOptionPane;  
* @author swg 
public class Main {  
     * @param args the command line arguments 
    public static void main(String[] args) {  
        java.awt.EventQueue.invokeLater(new Runnable() {  
            public void run() {  
                new NewJFrame().setVisible(true);  
class NewJFrame extends javax.swing.JFrame {  
    /** Creates new form NewJFrame */ 
    public NewJFrame() {  
        initComponents();  
    /** This method is called from within the constructor to 
     * initialize the form. 
     * WARNING: Do NOT modify this code. The content of this method is 
     * always regenerated by the Form Editor. 
    @SuppressWarnings("unchecked")  
    // <editor-fold defaultstate="collapsed" desc="Generated Code">  
    private void initComponents() {  
        jMenuBar1 = new javax.swing.JMenuBar();  
        jMenu1 = new javax.swing.JMenu();  
        jMenuItem1 = new javax.swing.JMenuItem();  
        jMenu2 = new javax.swing.JMenu();  
        setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);  
        jMenu1.setText("File");  
        jMenuItem1.setText("jMenuItem1");  
        jMenuItem1.addActionListener(new java.awt.event.ActionListener() {  
            public void actionPerformed(java.awt.event.ActionEvent evt) {  
                jMenuItem1ActionPerformed(evt);  
        jMenu1.add(jMenuItem1);  
        jMenuBar1.add(jMenu1);  
        jMenu2.setText("Edit");  
        jMenuBar1.add(jMenu2);  
        setJMenuBar(jMenuBar1);  
        javax.swing.GroupLayout layout = new javax.swing.GroupLayout(getContentPane());  
        getContentPane().setLayout(layout);  
        layout.setHorizontalGroup(  
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)  
            .addGap(0, 400, Short.MAX_VALUE)  
        layout.setVerticalGroup(  
            layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)  
            .addGap(0, 279, Short.MAX_VALUE)  
        pack();  
    }// </editor-fold>  
    private void jMenuItem1ActionPerformed(java.awt.event.ActionEvent evt) {  
        int result = JOptionPane.showConfirmDialog(this, "hello");  
    // Variables declaration - do not modify  
    private javax.swing.JMenu jMenu1;  
    private javax.swing.JMenu jMenu2;  
    private javax.swing.JMenuBar jMenuBar1;  
    private javax.swing.JMenuItem jMenuItem1;  
    // End of variables declaration  
}

Answer 1

It won't comfort you much, but I had similar problems on Solaris 10, and at the time we traked them down to a known bug [6262392|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6262392]. The status of this latter is "Closed, will not fix", although it is not explained why...
It's probably because the entry is itself related to another, more general, bug [6888200|http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=b6eea0fca217effffffffe82413c8a9fce16?bug_id=6888200], which is still open.
So it is unclear whether this problem will be worked upon (I suspect that yes) and when (I suspect that... not too soon, as it's been dormant for several years!).
None of our attempts (+toFront(...)+ etc...) solved the issue either, and they only moderately lowered the frequency of occurrence.
I left the project since then, but I was said that the workaround mentioned in the first bug entry (see comments) doesn't work, whereas switching to Java Desktop instead of CDE reduced the frequency of the issues (without fixing them completely either) - I don't know whether it's an option on HPUX.
Edited by: jduprez on Jul 9, 2010 11:29 AM