This is 911 at The Swing Connection -- a column that provides answers (including available workarounds) to common problems reported by developers using Swing.

We call the column 911 because that's the police emergency number in the United States. If you live somewhere else, your phone system may have a different emergency number. But you get the idea.

Before you tell us about a problem you're having via swing-feedback e-mail, look for a solution on this page. If other developers have asked us the same question that you've been wondering about, this is where you might find an instant answer.

The Case of the Missing JInternalFrames

Q. Starting with the Kestrel beta release, none of my JInternalFrames show up! What happened to them?

A. Beginning with the Kestrel beta release, you need to set the visibility of each JInternalFrame to true in order to have it show up on the screen; prior to Kestrel Beta, the visibility of JInternalFrames was true by default.

Why the change? The rule for default visibility in Swing is that only top-level components, such as JFrame and JDialog, have default visibility false; the remaining components have default visibility true. This is so that once a JFrame is constructed, one call to setVisible(true) on the JFrame will show it and all of its contents.

JInternalFrame is an anomaly: although it's not really a top-level component, it needs to behave like a JFrame in many ways. In particular, it needs to fire JInternalFrame events corresponding to Window events on JFrames. One such event, INTERNAL_FRAME_OPENED, is fired in response to the initial visibility change from false to true; with no such change prior to Kestrel Beta, the event wasn't being fired (bug #4138320).

In order to fix this bug, and to make JInternalFrame more compatible with its heavyweight cousin JFrame, the default visibility of JInternalFrame has been changed to false beginning with Kestrel Beta. Therefore, to show an internal frame, just add the call to setVisible(true) after adding the frame to its parent.

(Hania Gajewska)

Swing 1.1.1 beta bug fixes and the Java^TM 2 environment

Q: I want to use the Swing 1.1.1 beta bug fixes in my Java 2^TM environment. How and when can I get them?

A: The latest release of Swing available to developers -- Swing 1.1.1 Beta 2 -- contains many bug fixes, plus a new text-package enhancement (introduced in Beta 1) that lets you put HTML text in buttons and labels.

Swing 1.1.1 Beta 2-- which requires JDK 1.1.7. -- is available for downloading from the Java^TM Developer Connection^SM Web site. It will also be made available as part of an upcoming Java^TM 2 (JDK 1.2) maintenance release later this spring.

We issued the unbundled version of this new Swing release first because it was easier to provide a beta release with Swing sitting on top of JDK 1.1 software than to do a full Java 2 technology beta release. Also, Swing 1.1.1 Beta 2 contains many bug fixes, and the Swing team wants to get feedback on them as quickly as possible. We believe this early feedback will result in a higher-quality release for the Java 2 environment.

Although the sources for the unbundled and Java 2 platform versions of Swing are almost identical, there are some differences to deal with regarding the Java 2D^TM API, AWT, and security -- which means we can't support running the unbundled version of the Swing classes in the Java 2 environment (although it may work for applications under certain scenarios). We are currently working closely with the rest of the JDK team to complete the Java 2 platform maintenance release so that our Swing1.1.1 bug fixes will be available for both JDK1.1 and Java 2 platform environments.

For more details about Swing 1.1.1 beta 1, see the CHANGES.txt file that cames with the release. To find out how to download Swing releases, see the JFC Web site.

Repainting problems with Windows 98

Q. When I run Swing in JDK 1.2 with Windows 98, I see all sorts of repaint problems. In particular, the cursor disappears underneath the components. Why?

A. This problem is caused by a bug in Java 2D API in JDK 1.2 software (Bug No. 4196958). It occur only when you use Windows 98 Themes to customize your desktop. This operation can install cursors with which the Java 2D API does not deal properly. We hope to fix this behaviour in a future release. Until then, the workaround is to turn off Themes in Windows 98.

The mysterious disappearing wait cursor

Q: When I set the WAIT_CURSOR on my JFrame using setCursor(), why doesn't the wait cursor appear when the mouse is inside the JFrame?

A. Theoretically, invoking setCursor() on a container object (including a top-level object, such as a JFrame) should automatically cause that cursor to be displayed on all descendents of that container that don't have an explicit cursor set. Unfortunately, there are a couple AWT cursor bugs (Nos. 4114073 and 4160474) which prevent this operation from working correctly on lightweight components (and, since a JFrame is completely filled with a lightweight "content pane," this bug really affects most Swing programs).

Both these bugs will be fixed in JDK1.1.8 and in a future 1.2.X release. However, it's possible to use Swing's GlassPane to workaround the problem in the mean time. Following is some sample code which shows how to implement this in a JFrame:

class BusyFrame extends JFrame {

   public BusyFrame() {
      //
      // Set up glasspane to handle making the Frame "busy"
      //
      Component glass = getGlassPane();
      glass.setCursor(Cursor.getPredefinedCursor
                 (Cursor.WAIT_CURSOR));
      // Adding a mouseListener serves 2 purposes:
      // 1) it's a workaround to an AWT lightweight cursor bug
      // which prevents the cursor from showing unless there
      // is a mouse listener set on the lightweight.
      // 2) the mouseListener catches all input on the Frame,
      // making the underlying components 'inactive' to input.
      //
      glass.addMouseListener(new MouseAdapter() {
         public void mousePressed(MouseEvent e) {}
      });
   }

   public void setBusy(boolean busy) {
      getGlassPane().setVisible(busy);
   }
}

The case of the disappearing menu

Q. Is there any way to make the Swing menu control the Menu display? That is to say, if one of my application's menus or submenus goes off the screen in a normal display, do I have the option to display it in such a way that it is always completely seen by the user?

To illustrate, suppose my app has a set of menus something like this:

Menu1 Menu2 Menu3 Menu4 Menu5

In this case, if "sub-SubMenu5" goes off the screen, I would like to display it on the left-hand-side of "SubMenu5" instead of the right-hand-side, as would be the case in Microsoft Windows. Whether automatically or programatically, I would like to see the menu displayed depending upon the display area -- in other words, the menu should be displayed in such a way it is completely viewed and no part of it is hidden.

A. The current implementation of JMenu does not do anything to ensure that its popup menu is displayed onscreen. This shortcoming will be fixed in a future version. Still, it is very easy to work around this problem, even in the versions of Swing that are currently available for download! Click the Download button to see an example that adds a very simple (if not particularly efficient) heuristic for popup menu placement.

(Georges Saab)

Text clipped in Option dialogs

Q. When I bring up an option dialog in JDK 1.1.6, often the text in the message and buttons is clipped (and contains an ellipsis "...".) Why isn't the Option Pane creating these components to be large enough to hold all the text?

A. This phenomenon was caused by an AWT regression for the Win32 platform in JDK 1.1.6. (The problem did not exist in JDK 1.1.5). The bug was fixed in JDK 1.1.7.

The phenomenon occurred when AWT created the peer for the dialog. The dialog turned out to be be two pixels smaller than the size which the Swing JOptionPane was requesting. Consequently, all the components were forced to be smaller than their preferred sizes. (Bug ID No. 4135218)..

If it looks like a Mac and feels like a Mac . . .

Q: Why can I run the Mac L&F only on Mac OS?

A: We have not determined that we have the right to deliver the Mac look and feel on platforms other than MacOS. If Apple were to confirm our right to deliver this look and feel on other operating systems, we would be delighted to remove the lock. To date, Apple has declined to do this.

Although you cannot use the new Mac L&F on non-Macintosh platforms, there is a way to examine the source code so developers can use it as an example of how to create a custom L&F. The Mac L&F is distributed in "stuffed-binhexed" format, which is standard for the Macintosh. If you develop on the Microsoft Windows platform and would like to examine the source code for the Mac L&F then you can do that by downloading and using a program called Aladdin Expander for Microsoft Windows. You can download Aladdin Expander from this URL:

http://www.aladdinsys.com/expander/index.html

When you have downloaded Aladdin Expander, you can use it to decode the Mac L&F file posted on the JDC.

Organic L&F, R.I.P.

Q: What happened to the Organic look and feel, one of the first cross-platform L&Fs created for Swing?

A: After careful consideration, Java Software, Sun Microsystems, has decided to standardize on one cross-platform look and feel: the Java L&F (previously code-named Metal). Therefore the Swing team can no longer support, or release any updates to, the Organic look and feel.

It's also important to note that due to recent changes in Swing's pluggable look-and-feel (plaf) architecture, the Organic L&F code base is no longer compatible with the current version of Swing. Because of this lack of compatibility, and because of overwhelming developer support for the current Java look and feel, we have also decided not to release the source for the Organic L&F at this time.

(The Swing Team)

Swing performance revisited

Q: Could you provide an update on Swing performance? That's a hot topic on the newsgroups lately.

A: Swing 1.1 beta includes many performance enhancements. The Swing team has been working hard to find and eliminate performance bottlenecks. We've concentrated on removing allocation of temporary objectors during repetitive operations. This includes drastic reductions in the number of Rectangle, Dimension, and String objects created during layout and painting. We've also made key improvements to Swing's core repainting engine to improve efficiency.

Overall, many operations have been sped-up by around two times (some more, some less). However, this isn't the end of our performance-tuning efforts. We're already working on more performance enhancements (such as faster InternalFrame dragging) that will appear in future releases of Swing.

(Steve Wilson)

JSplitPane divider seems to lock up

Q: When a JScrollPane is used within a JSplitPane, the divider sometimes seem to lock up and can't be moved around anymore. Why is that?

A: JSplitPane uses the defined minimum/preferred sizes of the components it contains to determine if and how far the divider can be moved. A JScrollPane uses the preferred size of the component it contains as its own minimum size, if the minimum size for the JScrollPane is not being set explicitly. This means that, depending on the preferred size of whatever the JScrollPane contains, this value will be used for the layout of the components in JSplitPane.

If the JScrollPane contains a JTextArea with a long text in it, it is very unlikely that the divider of the JSplitPane will be movable anymore. To avoid this problem, define the minimum size of the JScrollPane explicitly using the following method:

    JScrollPane.setMinimumSize(Dimension)

(Ralph Kar)

Button mnemonics are back

Q: What was wrong with button mnemonics in Swing 1.0.2?

A. In Swing 1.0.2, button mnemonics were accidentally turned off. They were turned back on and became available again with the release of Swing 1.0.3.

(Jeff Dinkins)

Quieting an annoying warning

Q: Why does my applet cause a warning message to be printed on the browser's "Java Console?"

A: Most browsers unconditionally print a console message when Swing makes its on- time AWT system event queue check; IE4 prints a backtrace, and Navigator prints a short message.

If you're deploying an applet that does not serve double duty as part of an application, you can short-circuit the event-queue check by setting a special property on the JApplet's root pane, using a technique similar to this:

         /* This will prevent the "SystemEventQueue"
          * access message from appearing in the Java console
          * when this applet is run in a browser.
          */

          applet.getRootPane().putClientProperty
          ("defeatSystemEventQueueCheck", Boolean.TRUE);

(Hans Muller)

Dialog deadlocks

Q: On Windows NT, when I dismiss modal JDialogs (such as the Option dialogs in the SwingSet demo), the GUI often hangs, or sometimes paints incorrectly. This happens with JDK versions up to JDK 1.1.5. What's the problem?

A: In the versioins of JDK that you are speaking of, the show() method on modal dialogs blocks until the dialog is hidden. Consequently, if it's invoked from the current event-dispatching thread, the AWT Dialog implementation uses another dispatching thread (the "proxy") to process events until the modal dialog is hidden and the show() method returns.

Unfortunately, the implementation left a small window of opportunity for both these event-dispatching threads to be processing events simultaneously! This situation would commonly deadlock Swing (especially if the underlying Frame contained any Swing text components).

This problem seemed to occur most frequently with very fast Windows NT systems. It has was fixed in JDK 1.1.6 (Bug No. #4122683).

NOTE: if you are still having deadlock problems when displaying modal dialogs in JDK 1.1.6 or later, the likely cause is that your program is holding onto locks when calling show() (which will block while holding the locks). In particular, you should make sure you are not overriding show() to be synchronized -- else you are guaranteed to deadlock!

(Amy Fowler)

Flickery flashing

Q: On Windows NT or Windows 95, when I dismiss modal JDialogs (such as the Option dialogs in SwingSet), the entire underlying JFrame repaints, which causes annoying flashing! How can I fix this?

A: This flashing was caused by a Win32-specific bug in the AWT. It was fixed in JDK 1.1.7. (Bug No. 4122094).

(Amy Fowler)

One JOptionPane bug hatches another

Q: When I bring up an option dialog using the JOptionPane.showXXDialog() methods in Swing 1.0.2, why isn't my title being properly displayed in the dialog? It always displays the title from the first option dialog shown.

A: In Swing1.0.2, we implemented a workaround for Solaris bug that caused dialog.dispose() to crash the VM). Under the workaround, option panes re-use Dialog instances from a shared pool. Unfortunately, this workaround tickled a bug in the Win32 AWT implementation (Bug No. 4120856) that caused the setTitle() method to fail on modal dialogs (and because we were re-using dialogs, we were depending on the setTitle() function). In Swing1.1 Beta 2, we changed the JOptionPane in such a way that it no longer performed this workaround when running on a Win32 platform. So you should no longer be encountering this problem.

(Amy Fowler