A lightweight container used behind the scenes by
For task-oriented information on functionality provided by root panes
see How to Use Root Panes,
a section in The Java Tutorial.
The following image shows the relationships between the classes that use root panes.
The "heavyweight" components (those that delegate to a peer, or native component on the host system) are shown with a darker, heavier box. The four heavyweight JFC/Swing containers (
JApplet) are shown in relation to the AWT classes they extend. These four components are the only heavyweight containers in the Swing library. The lightweight container
JInternalFrameis also shown. All five of these JFC/Swing containers implement the
RootPaneContainerinterface, and they all delegate their operations to a
JRootPane(shown with a little "handle" on top).
getRootPanecan be used to obtain the
JRootPanethat contains a given component.
JRootpaneis made up of a
glassPane, an optional
menuBar, and a
glassPanesits over the top of everything, where it is in a position to intercept mouse movements. Since the
contentPane) can be an arbitrary component, it is also possible to set up the
glassPanefor drawing. Lines and images on the
glassPanecan then range over the frames underneath without being limited by their boundaries.
menuBar component is optional,
glassPane always exist.
Attempting to set them to
null generates an exception.
To add components to the
JRootPane (other than the
optional menu bar), you add the object to the
JRootPane, like this:
rootPane.getContentPane().add(child);The same principle holds true for setting layout managers, removing components, listing children, etc. All these methods are invoked on the
contentPaneinstead of on the
Note: The default layout manager for theIf a
BorderLayoutmanager. However, the
JRootPaneuses a custom
LayoutManager. So, when you want to change the layout manager for the components you added to a
JRootPane, be sure to use code like this:rootPane.getContentPane().setLayout(new BoxLayout());
JMenuBarcomponent is set on the
JRootPane, it is positioned along the upper edge of the frame. The
contentPaneis adjusted in location and size to fill the remaining area. (The
contentPaneare added to the
layeredPanecomponent at the
layeredPane is the parent of all children in the
JRootPane -- both as the direct parent of the menu and
the grandparent of all components added to the
It is an instance of
which provides the ability to add components at several layers.
This capability is very useful when working with menu popups,
dialog boxes, and dragging -- situations in which you need to place
a component on top of all other components in the pane.
glassPane sits on top of all other components in the
That provides a convenient place to draw above all other components,
and makes it possible to intercept mouse events,
which is useful both for dragging and for drawing.
Developers can use
setVisible on the
to control when the
glassPane displays over the other children.
By default the
glassPane is not visible.
LayoutManager used by
glassPanefills the entire viewable area of the
JRootPane(bounds - insets).
layeredPanefills the entire viewable area of the
JRootPane. (bounds - insets)
menuBaris positioned at the upper edge of the
contentPanefills the entire viewable area, minus the
menuBar, if present.
JRootPaneview hierarchy are ignored.
If you replace the
LayoutManager of the
you are responsible for managing all of these views.
So ordinarily you will want to be sure that you
change the layout manager for the
contentPane rather than
The painting architecture of Swing requires an opaque
to exist in the containment hierarchy above all other components. This is
typically provided by way of the content pane. If you replace the content
pane, it is recommended that you make the content pane opaque
by way of
setOpaque(true). Additionally, if the content pane
will need to completely fill in the background in an opaque color in
Warning: Swing is not thread safe. For more information see Swing's Threading Policy.
Serialized objects of this class will not be compatible with
future Swing releases. The current serialization support is
appropriate for short term storage or RMI between applications running
the same version of Swing. As of 1.4, support for long term storage
of all JavaBeans™
has been added to the