///Tip on Mixing Heavyweight and Lightweight Java Components

Tip on Mixing Heavyweight and Lightweight Java Components

The Problem

 I have a JComboBox displayed in a Panel container that is embedded in a Frame window. When I select the down arrow to make a popup window appear in order to change the selection within the entryfield, the popup window appears to be clipped. In fact, when I do some further investigation, I notice that the popup, which lists the choices to select from, appears behind the Frame component. Is this a z-order problem?

The answer


Z-order refers to how objects are layered on top of each other in a container. If an object overlays part of another control in the same container, then it is in a different layer. The layers are known as x, y, and z, thus giving us the name z-order. You can purposely set the z-order; however, I found this did not solve the problem described above. So I had to dig a little deeper.

When Java APIs were first introduced, the AWT classes consisted of mostly heavyweight objects. (One exception to this was the Component class.) The objects are heavy because they require the simultaneous creation of what is known as a peer (that is, a platform-dependent object) in order to be displayed on the screen. The peer, also known as a native window, changes based on which platform you are running on. On the other hand, most Swing classes that extend AWT do not make use of a peer object so they don’t carry the baggage that the original AWT classes do; hence the name lightweight. A lightweight component is not associated with a native opaque window. Therefore, no matter where you run your program, you will get the same look and feel, and most importantly there is no native code involved. In other words, if you use a non-Swing button, you will get a button whose look is based on the operating system (OS); whereas, if you use a Swing button, you will get a drawing of an object that appears to be a button independent of the OS. It is also important to point out that even though some of the classes make use of native OS code, this does not inhibit an application’s portability. The native code is built into the Java run-time environment, not your application.

You may have noticed that I said most Swing classes that extend AWT do not make use of a peer. JFrame does not follow this model. JFrame extends the Frame class, which is a heavyweight object. Consequently, JFrame is a heavyweight object as well. Other Swing classes that are heavyweight are JWindow, JDialog, and JApplet.

All Swing components are derived from AWT components. For example, if you travel up the hierarchical tree, you will see JLabel is derived from JComponent, which is derived from AWT Component. The AWT Component is a lightweight object so therefore, the JLabel is lightweight. Label also subclasses the Component class, so it too is considered lightweight.

The problem described above involves a Panel that is embedded in a heavyweight Frame object. The popup in the JCombobox is lightweight. Consequently, the Frame component is in the way of the JCombobox’s popup, thus hiding it in the background. The native peer window that is created with the Frame component is opaque, so it can’t be used to implement transparent areas.

The resolution

table cellspacing=”0″ cellpadding=”5″ width=”30%” align=”right” border=”1″>

An exception to the rule

The JComboBox class differs from other Swing classes in that it does offer a method called setLightWeightPopupEnabled(Boolean aFlag). This method allows you make the popup a heavyweight object so that it will appear on top of a Frame window. This is the exception rather than the rule.

Now that we know what the problem is, how do we handle it? JDK 1.1 implemented the Lightweight UI Framework. The Swing classes use the Lightweight UI Framework, giving you the ability to extend the AWT Component and Container classes that do not have native opaque windows. Classes that currently subclass the heavyweight objects can adapt to this model by changing the class they subclass from.

The bottom line is that you should not mix heavyweight and lightweight objects. Follow one path or the other so that your application has a unified and consistent view across platforms. The advantages of using all lightweight objects include supporting transparent areas, the lack of additional peer classes (thus improving performance), and the ability to say that you used 100% Java code.


  • Learn more about the Java timer facilities in "Using Timers in Swing Applications."
  • Read about the Project Swing application code, which uses lightweight components and other Project Swing features shown in "Writing Advanced Applications."
  • 2010-05-26T17:12:35+00:00 October 1st, 2003|Java|0 Comments

    About the Author:

     Laura Bennett is an Advisory Programmer at IBM. She has been a software developer for the last 15 years and has been writing C++ and Java code for the last 5 years. She is the technical lead for the Java zone on developerWorks and contributes to the zone with code and papers. Laura earned a Masters degree in Computer Science from Columbia University and a Bachelors Degree in Computer Science from Pace University in New York. She can be reached at lbenn@us.ibm.com.

    Leave A Comment