This class provides default implementations for the JFC Action
interface. Standard behaviors like the get and set methods for
Action object properties (icon, text, and enabled) are defined
here. The developer need only subclass this abstract class and
define the actionPerformed method.

Warning:
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 java.beans package.
Please see XMLEncoder.

Defines common behaviors for buttons and menu items.

Buttons can be configured, and to some degree controlled, by
Actions.  Using an
Action with a button has many benefits beyond directly
configuring a button.  Refer to
Swing Components Supporting Action for more
details, and you can find more information in How
to Use Actions, a section in The Java Tutorial.

For further information see
How to Use Buttons, Check Boxes, and Radio Buttons,
a section in The Java Tutorial.

Warning:
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 java.beans package.
Please see XMLEncoder.

A base class for CellEditors, providing default
implementations for the methods in the CellEditor
interface except getCellEditorValue().
Like the other abstract implementations in Swing, also manages a list
of listeners.


Warning:
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 java.beans package.
Please see XMLEncoder.

The abstract definition for the data model that provides
a List with its contents.

Warning:
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 java.beans package.
Please see XMLEncoder.

This class provides the ChangeListener part of the
SpinnerModel interface that should be suitable for most concrete SpinnerModel
implementations.  Subclasses must provide an implementation of the
setValue, getValue, getNextValue and
getPreviousValue methods.

 enabled
 All
 The isEnabled method


 toolTipText
 All
 SHORT_DESCRIPTION


 actionCommand
 All
 ACTION_COMMAND_KEY


 mnemonic
 All buttons
 MNEMONIC_KEY
 A null value or Action results in the
     button's mnemonic property being set to
     '\0'.

 text
 All buttons
 NAME
 If you do not want the text of the button to mirror that
     of the Action, set the property
     hideActionText to true.  If
     hideActionText is true, setting the
     Action changes the text of the button to
     null and any changes to NAME
     are ignored.  hideActionText is useful for
     tool bar buttons that typically only show an Icon.
     JToolBar.add(Action) sets the property to
     true if the Action has a
     non-null value for LARGE_ICON_KEY or
     SMALL_ICON.

 displayedMnemonicIndex
 All buttons
 DISPLAYED_MNEMONIC_INDEX_KEY
 If the value of DISPLAYED_MNEMONIC_INDEX_KEY is
     beyond the bounds of the text, it is ignored.  When
     setAction is called, if the value from the
     Action is null, the displayed
     mnemonic index is not updated.  In any subsequent changes to
     DISPLAYED_MNEMONIC_INDEX_KEY, null
     is treated as -1.

 icon
 All buttons except of JCheckBox,
 JToggleButton and JRadioButton.
 either LARGE_ICON_KEY or
     SMALL_ICON
The JMenuItem subclasses only use
    SMALL_ICON.  All other buttons will use
    LARGE_ICON_KEY; if the value is null they
    use SMALL_ICON.

 accelerator
 All JMenuItem subclasses, with the exception of
     JMenu.
 ACCELERATOR_KEY


 selected
 JToggleButton, JCheckBox,
     JRadioButton, JCheckBoxMenuItem and
     JRadioButtonMenuItem
 SELECTED_KEY
 Components that honor this property only use
     the value if it is non-null. For example, if
     you set an Action that has a null
     value for SELECTED_KEY on a JToggleButton, the
     JToggleButton will not update it's selected state in
     any way. Similarly, any time the JToggleButton's
     selected state changes it will only set the value back on
     the Action if the Action has a non-null
     value for SELECTED_KEY.

     Components that honor this property keep their selected state
     in sync with this property. When the same Action is used
     with multiple components, all the components keep their selected
     state in sync with this property. Mutually exclusive
     buttons, such as JToggleButtons in a ButtonGroup,
     force only one of the buttons to be selected. As such, do not
     use the same Action that defines a value for the
     SELECTED_KEY property with multiple mutually
     exclusive buttons.

The Action interface provides a useful extension to the
ActionListener
interface in cases where the same functionality may be accessed by
several controls.

In addition to the actionPerformed method defined by the
ActionListener interface, this interface allows the
application to define, in a single place:

One or more text strings that describe the function. These strings
    can be used, for example, to display the flyover text for a button
    or to set the text in a menu item.
One or more icons that depict the function. These icons can be used
    for the images in a menu control, or for composite entries in a more
    sophisticated user interface.
The enabled/disabled state of the functionality. Instead of having
    to separately disable the menu item and the toolbar button, the
    application can disable the function that implements this interface.
    All components which are registered as listeners for the state change
    then know to disable event generation for that item and to modify the
    display accordingly.


This interface can be added to an existing class or used to create an
adapter (typically, by subclassing AbstractAction).
The Action object
can then be added to multiple Action-aware containers
and connected to Action-capable
components. The GUI controls can then be activated or
deactivated all at once by invoking the Action object's
setEnabled method.

Note that Action implementations tend to be more expensive
in terms of storage than a typical ActionListener,
which does not offer the benefits of centralized control of
functionality and broadcast of property changes.  For this reason,
you should take care to only use Actions where their benefits
are desired, and use simple ActionListeners elsewhere.


Swing Components Supporting Action

Many of Swing's components have an Action property.  When
an Action is set on a component, the following things
happen:

The Action is added as an ActionListener to
    the component.
The component configures some of its properties to match the
     Action.
The component installs a PropertyChangeListener on the
    Action so that the component can change its properties
    to reflect changes in the Action's properties.


The following table describes the properties used by
Swing components that support Actions.
In the table, button refers to any
AbstractButton subclass, which includes not only
JButton but also classes such as
JMenuItem. Unless otherwise stated, a
null property value in an Action (or a
Action that is null) results in the
button's corresponding property being set to null.



   Component Property
   Components
   Action Key
   Notes

     enabled
     All
     The isEnabled method


     toolTipText
     All
     SHORT_DESCRIPTION


     actionCommand
     All
     ACTION_COMMAND_KEY


     mnemonic
     All buttons
     MNEMONIC_KEY
     A null value or Action results in the
         button's mnemonic property being set to
         '\0'.

     text
     All buttons
     NAME
     If you do not want the text of the button to mirror that
         of the Action, set the property
         hideActionText to true.  If
         hideActionText is true, setting the
         Action changes the text of the button to
         null and any changes to NAME
         are ignored.  hideActionText is useful for
         tool bar buttons that typically only show an Icon.
         JToolBar.add(Action) sets the property to
         true if the Action has a
         non-null value for LARGE_ICON_KEY or
         SMALL_ICON.

     displayedMnemonicIndex
     All buttons
     DISPLAYED_MNEMONIC_INDEX_KEY
     If the value of DISPLAYED_MNEMONIC_INDEX_KEY is
         beyond the bounds of the text, it is ignored.  When
         setAction is called, if the value from the
         Action is null, the displayed
         mnemonic index is not updated.  In any subsequent changes to
         DISPLAYED_MNEMONIC_INDEX_KEY, null
         is treated as -1.

     icon
     All buttons except of JCheckBox,
     JToggleButton and JRadioButton.
     either LARGE_ICON_KEY or
         SMALL_ICON
    The JMenuItem subclasses only use
        SMALL_ICON.  All other buttons will use
        LARGE_ICON_KEY; if the value is null they
        use SMALL_ICON.

     accelerator
     All JMenuItem subclasses, with the exception of
         JMenu.
     ACCELERATOR_KEY


     selected
     JToggleButton, JCheckBox,
         JRadioButton, JCheckBoxMenuItem and
         JRadioButtonMenuItem
     SELECTED_KEY
     Components that honor this property only use
         the value if it is non-null. For example, if
         you set an Action that has a null
         value for SELECTED_KEY on a JToggleButton, the
         JToggleButton will not update it's selected state in
         any way. Similarly, any time the JToggleButton's
         selected state changes it will only set the value back on
         the Action if the Action has a non-null
         value for SELECTED_KEY.

         Components that honor this property keep their selected state
         in sync with this property. When the same Action is used
         with multiple components, all the components keep their selected
         state in sync with this property. Mutually exclusive
         buttons, such as JToggleButtons in a ButtonGroup,
         force only one of the buttons to be selected. As such, do not
         use the same Action that defines a value for the
         SELECTED_KEY property with multiple mutually
         exclusive buttons.


JPopupMenu, JToolBar and JMenu
all provide convenience methods for creating a component and setting the
Action on the corresponding component.  Refer to each of
these classes for more information.

Action uses PropertyChangeListener to
inform listeners the Action has changed.  The beans
specification indicates that a null property name can
be used to indicate multiple values have changed.  By default Swing
components that take an Action do not handle such a
change.  To indicate that Swing should treat null
according to the beans specification set the system property
swing.actions.reconfigureOnNull to the String
value true.

ActionMap provides mappings from
Objects
(called keys or Action names)
to Actions.
An ActionMap is usually used with an InputMap
to locate a particular action
when a key is pressed. As with InputMap,
an ActionMap can have a parent
that is searched for keys not defined in the ActionMap.
As with InputMap if you create a cycle, eg:


  ActionMap am = new ActionMap();
  ActionMap bm = new ActionMap():
  am.setParent(bm);
  bm.setParent(am);
some of the methods will cause a StackOverflowError to be thrown.

A class that implements an empty border with no size.
This provides a convenient base class from which other border
classes can be easily derived.

Warning:
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 java.beans package.
Please see XMLEncoder.

A class which implements a simple two-line bevel border.

Warning:
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 java.beans package.
Please see XMLEncoder.

Interface describing an object capable of rendering a border
around the edges of a swing component.
For examples of using borders see
How to Use Borders,
a section in The Java Tutorial.

In the Swing component set, borders supercede Insets as the
mechanism for creating a (decorated or plain) area around the
edge of a component.

Usage Notes:

Use EmptyBorder to create a plain border (this mechanism
    replaces its predecessor, setInsets).
Use CompoundBorder to nest multiple border objects, creating
    a single, combined border.
Border instances are designed to be shared. Rather than creating
    a new border object using one of border classes, use the
    BorderFactory methods, which produces a shared instance of the
    common border types.
Additional border styles include BevelBorder, SoftBevelBorder,
    EtchedBorder, LineBorder, TitledBorder, and MatteBorder.
To create a new border class, subclass AbstractBorder.

A composite Border class used to compose two Border objects
into a single border by nesting an inside Border object within
the insets of an outside Border object.

For example, this class may be used to add blank margin space
to a component with an existing decorative border:



   Border border = comp.getBorder();
   Border margin = new EmptyBorder(10,10,10,10);
   comp.setBorder(new CompoundBorder(border, margin));

Warning:
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 java.beans package.
Please see XMLEncoder.

A class which provides an empty, transparent border which
takes up space but does no drawing.

Warning:
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 java.beans package.
Please see XMLEncoder.

A class which implements a simple etched border which can
either be etched-in or etched-out.  If no highlight/shadow
colors are initialized when the border is created, then
these colors will be dynamically derived from the background
color of the component argument passed into the paintBorder()
method.

Warning:
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 java.beans package.
Please see XMLEncoder.

A class which implements a line border of arbitrary thickness
and of a single color.

Warning:
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 java.beans package.
Please see XMLEncoder.

A class which provides a matte-like border of either a solid color
or a tiled icon.

Warning:
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 java.beans package.
Please see XMLEncoder.

A class which implements a raised or lowered bevel with
softened corners.

Warning:
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 java.beans package.
Please see XMLEncoder.

A class which implements a border of an arbitrary stroke.

Warning:
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 java.beans package.
Please see XMLEncoder.

A class which implements an arbitrary border
with the addition of a String title in a
specified position and justification.

If the border, font, or color property values are not
specified in the constructor or by invoking the appropriate
set methods, the property values will be defined by the current
look and feel, using the following property names in the
Defaults Table:

"TitledBorder.border"
"TitledBorder.font"
"TitledBorder.titleColor"


Warning:
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 java.beans package.
Please see XMLEncoder.

Factory class for vending standard Border objects.  Wherever
possible, this factory will hand out references to shared
Border instances.
For further information and examples see
How
to Use Borders,
a section in The Java Tutorial.

Defines the data model used by components like Sliders
and ProgressBars.
Defines four interrelated integer properties: minimum, maximum, extent
and value.  These four integers define two nested ranges like this:


minimum <= value <= value+extent <= maximum
The outer range is minimum,maximum and the inner
range is value,value+extent.  The inner range
must lie within the outer one, i.e. value must be
less than or equal to maximum and value+extent
must greater than or equal to minimum, and maximum
must be greater than or equal to minimum.
There are a few features of this model that one might find a little
surprising.  These quirks exist for the convenience of the
Swing BoundedRangeModel clients, such as Slider and
ScrollBar.


  The minimum and maximum set methods "correct" the other
  three properties to accommodate their new value argument.  For
  example setting the model's minimum may change its maximum, value,
  and extent properties (in that order), to maintain the constraints
  specified above.


  The value and extent set methods "correct" their argument to
  fit within the limits defined by the other three properties.
  For example if value == maximum, setExtent(10)
  would change the extent (back) to zero.


  The four BoundedRangeModel values are defined as Java Beans properties
  however Swing ChangeEvents are used to notify clients of changes rather
  than PropertyChangeEvents. This was done to keep the overhead of monitoring
  a BoundedRangeModel low. Changes are often reported at MouseDragged rates.




For an example of specifying custom bounded range models used by sliders,
see Separable model architecture
in A Swing Architecture Overview.

A lightweight container
that uses a BoxLayout object as its layout manager.
Box provides several class methods
that are useful for containers using BoxLayout --
even non-Box containers.


The Box class can create several kinds
of invisible components
that affect layout:
glue, struts, and rigid areas.
If all the components your Box contains
have a fixed size,
you might want to use a glue component
(returned by createGlue)
to control the components' positions.
If you need a fixed amount of space between two components,
try using a strut
(createHorizontalStrut or createVerticalStrut).
If you need an invisible component
that always takes up the same amount of space,
get it by invoking createRigidArea.

If you are implementing a BoxLayout you
can find further information and examples in
How to Use BoxLayout,
a section in The Java Tutorial.

Warning:
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 java.beans package.
Please see XMLEncoder.

An implementation of a lightweight component that participates in
layout but has no view.

Warning:
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 java.beans package.
Please see XMLEncoder.

A layout manager that allows multiple components to be laid out either
vertically or horizontally. The components will not wrap so, for
example, a vertical arrangement of components will stay vertically
arranged when the frame is resized.








Nesting multiple panels with different combinations of horizontal and
vertical gives an effect similar to GridBagLayout, without the
complexity. The diagram shows two panels arranged horizontally, each
of which contains 3 components arranged vertically.

 The BoxLayout manager is constructed with an axis parameter that
specifies the type of layout that will be done. There are four choices:

X_AXIS - Components are laid out horizontally
from left to right.

Y_AXIS - Components are laid out vertically
from top to bottom.

LINE_AXIS - Components are laid out the way
words are laid out in a line, based on the container's
ComponentOrientation property. If the container's
ComponentOrientation is horizontal then components are laid out
horizontally, otherwise they are laid out vertically.  For horizontal
orientations, if the container's ComponentOrientation is left to
right then components are laid out left to right, otherwise they are laid
out right to left. For vertical orientations components are always laid out
from top to bottom.

PAGE_AXIS - Components are laid out the way
text lines are laid out on a page, based on the container's
ComponentOrientation property. If the container's
ComponentOrientation is horizontal then components are laid out
vertically, otherwise they are laid out horizontally.  For horizontal
orientations, if the container's ComponentOrientation is left to
right then components are laid out left to right, otherwise they are laid
out right to left.  For vertical orientations components are always
laid out from top to bottom.

For all directions, components are arranged in the same order as they were
added to the container.

BoxLayout attempts to arrange components
at their preferred widths (for horizontal layout)
or heights (for vertical layout).
For a horizontal layout,
if not all the components are the same height,
BoxLayout attempts to make all the components
as high as the highest component.
If that's not possible for a particular component,
then BoxLayout aligns that component vertically,
according to the component's Y alignment.
By default, a component has a Y alignment of 0.5,
which means that the vertical center of the component
should have the same Y coordinate as
the vertical centers of other components with 0.5 Y alignment.

Similarly, for a vertical layout,
BoxLayout attempts to make all components in the column
as wide as the widest component.
If that fails, it aligns them horizontally
according to their X alignments.  For PAGE_AXIS layout,
horizontal alignment is done based on the leading edge of the component.
In other words, an X alignment value of 0.0 means the left edge of a
component if the container's ComponentOrientation is left to
right and it means the right edge of the component otherwise.

Instead of using BoxLayout directly, many programs use the Box class.
The Box class is a lightweight container that uses a BoxLayout.
It also provides handy methods to help you use BoxLayout well.
Adding components to multiple nested boxes is a powerful way to get
the arrangement you want.

For further information and examples see
How to Use BoxLayout,
a section in The Java Tutorial.

Warning:
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 java.beans package.
Please see XMLEncoder.

This class is used to create a multiple-exclusion scope for
a set of buttons. Creating a set of buttons with the
same ButtonGroup object means that
turning "on" one of those buttons
turns off all other buttons in the group.

A ButtonGroup can be used with
any set of objects that inherit from AbstractButton.
Typically a button group contains instances of
JRadioButton,
JRadioButtonMenuItem,
or JToggleButton.
It wouldn't make sense to put an instance of
JButton or JMenuItem
in a button group
because JButton and JMenuItem
don't implement the selected state.

Initially, all buttons in the group are unselected.

For examples and further information on using button groups see
How to Use Radio Buttons,
a section in The Java Tutorial.

Warning:
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 java.beans package.
Please see XMLEncoder.

State model for buttons.

This model is used for regular buttons, as well as check boxes
and radio buttons, which are special kinds of buttons. In practice,
a button's UI takes the responsibility of calling methods on its
model to manage the state, as detailed below:

In simple terms, pressing and releasing the mouse over a regular
button triggers the button and causes and ActionEvent
to be fired. The same behavior can be produced via a keyboard key
defined by the look and feel of the button (typically the SPACE BAR).
Pressing and releasing this key while the button has
focus will give the same results. For check boxes and radio buttons, the
mouse or keyboard equivalent sequence just described causes the button
to become selected.

In details, the state model for buttons works as follows
when used with the mouse:

Pressing the mouse on top of a button makes the model both
armed and pressed. As long as the mouse remains down,
the model remains pressed, even if the mouse moves
outside the button. On the contrary, the model is only
armed while the mouse remains pressed within the bounds of
the button (it can move in or out of the button, but the model
is only armed during the portion of time spent within the button).
A button is triggered, and an ActionEvent is fired,
when the mouse is released while the model is armed
- meaning when it is released over top of the button after the mouse
has previously been pressed on that button (and not already released).
Upon mouse release, the model becomes unarmed and unpressed.

In details, the state model for buttons works as follows
when used with the keyboard:

Pressing the look and feel defined keyboard key while the button
has focus makes the model both armed and pressed. As long as this key
remains down, the model remains in this state. Releasing the key sets
the model to unarmed and unpressed, triggers the button, and causes an
ActionEvent to be fired.

This interface defines the methods any general editor should be able
to implement.

Having this interface enables complex components (the client of the
editor) such as JTree and
JTable to allow any generic editor to
edit values in a table cell, or tree cell, etc.  Without this generic
editor interface, JTable would have to know about specific editors,
such as JTextField, JCheckBox, JComboBox,
etc.  In addition, without this interface, clients of editors such as
JTable would not be able
to work with any editors developed in the future by the user
or a 3rd party ISV.

To use this interface, a developer creating a new editor can have the
new component implement the interface.  Or the developer can
choose a wrapper based approach and provide a companion object which
implements the CellEditor interface (See
DefaultCellEditor for example).  The wrapper approach
is particularly useful if the user want to use a 3rd party ISV
editor with JTable, but the ISV didn't implement the
CellEditor interface.  The user can simply create an object
that contains an instance of the 3rd party editor object and "translate"
the CellEditor API into the 3rd party editor's API.

This class is inserted in between cell renderers and the components that
use them.  It just exists to thwart the repaint() and invalidate() methods
which would otherwise propagate up the tree when the renderer was configured.
It's used by the implementations of JTable, JTree, and JList.  For example,
here's how CellRendererPane is used in the code the paints each row
in a JList:


  cellRendererPane = new CellRendererPane();
  ...
  Component rendererComponent = renderer.getListCellRendererComponent();
  renderer.configureListCellRenderer(dataModel.getElementAt(row), row);
  cellRendererPane.paintComponent(g, rendererComponent, this, x, y, w, h);

A renderer component must override isShowing() and unconditionally return
true to work correctly because the Swing paint does nothing for components
with isShowing false.

Warning:
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 java.beans package.
Please see XMLEncoder.

This is the abstract superclass for color choosers.  If you want to add
a new color chooser panel into a JColorChooser, subclass
this class.

Warning:
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 java.beans package.
Please see XMLEncoder.

A class designed to produce preconfigured "accessory" objects to
insert into color choosers.


Warning:
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 java.beans package.
Please see XMLEncoder.

A model that supports selecting a Color.

A generic implementation of ColorSelectionModel.

The editor component used for JComboBox components.

A data model for a combo box. This interface extends ListDataModel
and adds the concept of a selected item. The selected item is generally
the item which is visible in the combo box display area.

The selected item may not necessarily be managed by the underlying
ListModel. This disjoint behavior allows for the temporary
storage and retrieval of a selected item in the model.

A ComponentInputMap is an InputMap
associated with a particular JComponent.
The component is automatically notified whenever
the ComponentInputMap changes.
ComponentInputMaps are used for
WHEN_IN_FOCUSED_WINDOW bindings.

Graphics subclass supporting graphics debugging. Overrides most methods
from Graphics.  DebugGraphics objects are rarely created by hand.  They
are most frequently created automatically when a JComponent's
debugGraphicsOptions are changed using the setDebugGraphicsOptions()
method.

NOTE: You must turn off double buffering to use DebugGraphics:
      RepaintManager repaintManager = RepaintManager.currentManager(component);
      repaintManager.setDoubleBufferingEnabled(false);

A generic implementation of BoundedRangeModel.

Warning:
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 java.beans package.
Please see XMLEncoder.

The default implementation of a Button component's data model.

Warning:
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 java.beans package.
Please see XMLEncoder.

The default editor for table and tree cells.

Warning:
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 java.beans package.
Please see XMLEncoder.

The default model for combo boxes.

This is an implementation of the DesktopManager.
It currently implements the basic behaviors for managing
JInternalFrames in an arbitrary parent.
JInternalFrames that are not children of a
JDesktop will use this component
to handle their desktop-like actions.
This class provides a policy for the various JInternalFrame methods,
it is not meant to be called directly rather the various JInternalFrame
methods will call into the DesktopManager.

This class has been obsoleted by the 1.4 focus APIs. While client code may
still use this class, developers are strongly encouraged to use
java.awt.KeyboardFocusManager and
java.awt.DefaultKeyboardFocusManager instead.

Please see

How to Use the Focus Subsystem,
a section in The Java Tutorial, and the
Focus Specification
for more information.

Renders an item in a list.

Implementation Note:
This class overrides
invalidate,
validate,
revalidate,
repaint,
isOpaque,
and
firePropertyChange
solely to improve performance.
If not overridden, these frequently called methods would execute code paths
that are unnecessary for the default list cell renderer.
If you write your own renderer,
take care to weigh the benefits and
drawbacks of overriding these methods.



Warning:
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 java.beans package.
Please see XMLEncoder.

A subclass of DefaultListCellRenderer that implements UIResource.
DefaultListCellRenderer doesn't implement UIResource
directly so that applications can safely override the
cellRenderer property with DefaultListCellRenderer subclasses.

Warning:
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 java.beans package.
Please see XMLEncoder.

This class loosely implements the java.util.Vector
API, in that it implements the 1.1.x version of
java.util.Vector, has no collection class support,
and notifies the ListDataListeners when changes occur.
Presently it delegates to a Vector,
in a future release it will be a real Collection implementation.

Warning:
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 java.beans package.
Please see XMLEncoder.

Default data model for list selections.

Warning:
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 java.beans package.
Please see XMLEncoder.

An implementation of RowSorter that provides sorting and
filtering around a grid-based data model.
Beyond creating and installing a RowSorter, you very rarely
need to interact with one directly.  Refer to
TableRowSorter for a concrete
implementation of RowSorter for JTable.

Sorting is done based on the current SortKeys, in order.
If two objects are equal (the Comparator for the
column returns 0) the next SortKey is used.  If no
SortKeys remain or the order is UNSORTED, then
the order of the rows in the model is used.

Sorting of each column is done by way of a Comparator
that you can specify using the setComparator method.
If a Comparator has not been specified, the
Comparator returned by
Collator.getInstance() is used on the results of
calling toString on the underlying objects.  The
Comparator is never passed null.  A
null value is treated as occurring before a
non-null value, and two null values are
considered equal.

If you specify a Comparator that casts its argument to
a type other than that provided by the model, a
ClassCastException will be thrown when the data is sorted.

In addition to sorting, DefaultRowSorter provides the
ability to filter rows.  Filtering is done by way of a
RowFilter that is specified using the
setRowFilter method.  If no filter has been specified all
rows are included.

By default, rows are in unsorted order (the same as the model) and
every column is sortable. The default Comparators are
documented in the subclasses (for example, TableRowSorter).

If the underlying model structure changes (the
modelStructureChanged method is invoked) the following
are reset to their default values: Comparators by
column, current sort order, and whether each column is sortable. To
find the default Comparators, see the concrete
implementation (for example, TableRowSorter).  The default
sort order is unsorted (the same as the model), and columns are
sortable by default.

If the underlying model structure changes (the
modelStructureChanged method is invoked) the following
are reset to their default values: Comparators by column,
current sort order and whether a column is sortable.

DefaultRowSorter is an abstract class.  Concrete
subclasses must provide access to the underlying data by invoking
setModelWrapper. The setModelWrapper method
must be invoked soon after the constructor is
called, ideally from within the subclass's constructor.
Undefined behavior will result if you use a DefaultRowSorter without specifying a ModelWrapper.

DefaultRowSorter has two formal type parameters.  The
first type parameter corresponds to the class of the model, for example
DefaultTableModel.  The second type parameter
corresponds to the class of the identifier passed to the
RowFilter.  Refer to TableRowSorter and
RowFilter for more details on the type parameters.

DefaultRowSorter.ModelWrapper is responsible for providing
the data that gets sorted by DefaultRowSorter.  You
normally do not interact directly with ModelWrapper.
Subclasses of DefaultRowSorter provide an
implementation of ModelWrapper wrapping another model.
For example,
TableRowSorter provides a ModelWrapper that
wraps a TableModel.

ModelWrapper makes a distinction between values as
Objects and Strings.  This allows
implementations to provide a custom string
converter to be used instead of invoking toString on the
object.

A generic implementation of SingleSelectionModel.

Warning:
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 java.beans package.
Please see XMLEncoder.

DesktopManager objects are owned by a JDesktopPane object. They are responsible
for implementing L&F specific behaviors for the JDesktopPane. JInternalFrame
implementations should delegate specific behaviors to the DesktopManager. For
instance, if a JInternalFrame was asked to iconify, it should try:


   getDesktopPane().getDesktopManager().iconifyFrame(frame);
This delegation allows each L&F to provide custom behaviors for desktop-specific
actions. (For example, how and where the internal frame's icon would appear.)
This class provides a policy for the various JInternalFrame methods, it is not
meant to be called directly rather the various JInternalFrame methods will call
into the DesktopManager.

An event reported to a child component that originated from an
ancestor in the component hierarchy.

Warning:
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 java.beans package.
Please see XMLEncoder.

AncestorListener

Interface to support notification when changes occur to a JComponent or one
of its ancestors.  These include movement and when the component becomes
visible or invisible, either by the setVisible() method or by being added
or removed from the component hierarchy.

CaretEvent is used to notify interested parties that
the text caret has changed in the event source.

Warning:
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 java.beans package.
Please see XMLEncoder.

Listener for changes in the caret position of a text
component.

CellEditorListener defines the interface for an object that listens
to changes in a CellEditor

ChangeEvent is used to notify interested parties that
state has changed in the event source.

Warning:
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 java.beans package.
Please see XMLEncoder.

Defines an object which listens for ChangeEvents.

Interface for document change notifications.  This provides
detailed information to Document observers about how the
Document changed.  It provides high level information such
as type of change and where it occurred, as well as the more
detailed structural changes (What Elements were inserted and
removed).

Describes changes made to a specific element.

Enumeration for document event types

Interface for an observer to register to receive notifications
of changes to a text document.

The default implementation of
the Document interface (AbstractDocument) supports asynchronous
mutations.  If this feature is used (i.e. mutations are made
from a thread other than the Swing event thread), the listeners
will be notified via the mutating thread.  This means that
if asynchronous updates are made, the implementation of this
interface must be threadsafe!

The DocumentEvent notification is based upon the JavaBeans
event model.  There is no guarantee about the order of delivery
to listeners, and all listeners must be notified prior to making
further mutations to the Document.  This means implementations
of the DocumentListener may not mutate the source of the event
(i.e. the associated Document).

A class that holds a list of EventListeners.  A single instance
can be used to hold all listeners (of all types) for the instance
using the list.  It is the responsiblity of the class using the
EventListenerList to provide type-safe API (preferably conforming
to the JavaBeans spec) and methods which dispatch event notification
methods to appropriate Event Listeners on the list.

The main benefits that this class provides are that it is relatively
cheap in the case of no listeners, and it provides serialization for
event-listener lists in a single place, as well as a degree of MT safety
(when used correctly).

Usage example:
   Say one is defining a class that sends out FooEvents, and one wants
to allow users of the class to register FooListeners and receive
notification when FooEvents occur.  The following should be added
to the class definition:


EventListenerList listenerList = new EventListenerList();
FooEvent fooEvent = null;

public void addFooListener(FooListener l) {
    listenerList.add(FooListener.class, l);
}

public void removeFooListener(FooListener l) {
    listenerList.remove(FooListener.class, l);
}


// Notify all listeners that have registered interest for
// notification on this event type.  The event instance
// is lazily created using the parameters passed into
// the fire method.

protected void fireFooXXX() {
    // Guaranteed to return a non-null array
    Object[] listeners = listenerList.getListenerList();
    // Process the listeners last to first, notifying
    // those that are interested in this event
    for (int i = listeners.length-2; i>=0; i-=2) {
        if (listeners[i]==FooListener.class) {
            // Lazily create the event:
            if (fooEvent == null)
                fooEvent = new FooEvent(this);
            ((FooListener)listeners[i+1]).fooXXX(fooEvent);
        }
    }
}
foo should be changed to the appropriate name, and fireFooXxx to the
appropriate method name.  One fire method should exist for each
notification method in the FooListener interface.

Warning:
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 java.beans package.
Please see XMLEncoder.

HyperlinkEvent is used to notify interested parties that
something has happened with respect to a hypertext link.

Warning:
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 java.beans package.
Please see XMLEncoder.

Defines the ENTERED, EXITED, and ACTIVATED event types, along
with their string representations, returned by toString().

HyperlinkListener

An abstract adapter class for receiving internal frame events.
The methods in this class are empty. This class exists as
convenience for creating listener objects, and is functionally
equivalent to the WindowAdapter class in the AWT.

See How to Write an Internal Frame Listener
in The Java Tutorial

An AWTEvent that adds support for
JInternalFrame objects as the event source.  This class has the
same event types as WindowEvent,
although different IDs are used.
Help on handling internal frame events
is in
How to Write an Internal Frame Listener,
a section in The Java Tutorial.

Warning:
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 java.beans package.
Please see XMLEncoder.

The listener interface for receiving internal frame events.
This class is functionally equivalent to the WindowListener class
in the AWT.

See How to Write an Internal Frame Listener
in The Java Tutorial for further documentation.

Defines an event that encapsulates changes to a list.

Warning:
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 java.beans package.
Please see XMLEncoder.

ListDataListener

An event that characterizes a change in selection. The change is limited to a
a single inclusive interval. The selection of at least one index within the
range will have changed. A decent ListSelectionModel implementation
will keep the range as small as possible. ListSelectionListeners will
generally query the source of the event for the new selected status of each
potentially changed row.

Warning:
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 java.beans package.
Please see XMLEncoder.

The listener that's notified when a lists selection value
changes.

MenuDragMouseEvent is used to notify interested parties that
the menu element has received a MouseEvent forwarded to it
under drag conditions.

Warning:
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 java.beans package.
Please see XMLEncoder.

Defines a menu mouse-drag listener.

MenuEvent is used to notify interested parties that
the menu which is the event source has been posted,
selected, or canceled.

Warning:
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 java.beans package.
Please see XMLEncoder.

MenuKeyEvent is used to notify interested parties that
the menu element has received a KeyEvent forwarded to it
in a menu tree.

Warning:
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 java.beans package.
Please see XMLEncoder.

MenuKeyListener

Defines a listener for menu events.

An empty implementation of the MouseInputListener interface, provided
as a convenience to simplify the task of creating listeners, by extending
and implementing only the methods of interest. This class also provides an
empty implementation of the MouseWheelListener interface, through
its extension from AWT's MouseAdapter.

A listener implementing all the methods in both the MouseListener and
MouseMotionListener interfaces.

PopupMenuEvent only contains the source of the event which is the JPoupMenu
sending the event

Warning:
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 java.beans package.
Please see XMLEncoder.

A popup menu listener

RowSorterEvent provides notification of changes to
a RowSorter.  Two types of notification are possible:

Type.SORT_ORDER_CHANGED: indicates the sort order has
    changed.  This is typically followed by a notification of:
Type.SORTED: indicates the contents of the model have
    been transformed in some way.  For example, the contents may have
    been sorted or filtered.

RowSorterListeners are notified of changes to a
RowSorter.

This subclass of java.beans.PropertyChangeSupport is almost
identical in functionality. The only difference is if constructed with
SwingPropertyChangeSupport(sourceBean, true) it ensures
listeners are only ever notified on the Event Dispatch Thread.

TableColumnModelEvent is used to notify listeners that a table
column model has changed, such as a column was added, removed, or
moved.

Warning:
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 java.beans package.
Please see XMLEncoder.

TableColumnModelListener defines the interface for an object that listens
to changes in a TableColumnModel.

TableModelEvent is used to notify listeners that a table model
has changed. The model event describes changes to a TableModel
and all references to rows and columns are in the co-ordinate
system of the model.
Depending on the parameters used in the constructors, the TableModelevent
can be used to specify the following types of changes:



TableModelEvent(source);              //  The data, ie. all rows changed
TableModelEvent(source, HEADER_ROW);  //  Structure change, reallocate TableColumns
TableModelEvent(source, 1);           //  Row 1 changed
TableModelEvent(source, 3, 6);        //  Rows 3 to 6 inclusive changed
TableModelEvent(source, 2, 2, 6);     //  Cell at (2, 6) changed
TableModelEvent(source, 3, 6, ALL_COLUMNS, INSERT); // Rows (3, 6) were inserted
TableModelEvent(source, 3, 6, ALL_COLUMNS, DELETE); // Rows (3, 6) were deleted

It is possible to use other combinations of the parameters, not all of them
are meaningful. By subclassing, you can add other information, for example:
whether the event WILL happen or DID happen. This makes the specification
of rows in DELETE events more useful but has not been included in
the swing package as the JTable only needs post-event notification.

Warning:
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 java.beans package.
Please see XMLEncoder.

TableModelListener defines the interface for an object that listens
to changes in a TableModel.

An event used to identify a single path in a tree.  The source
returned by getSource will be an instance of JTree.

For further documentation and examples see
the following sections in The Java Tutorial:
How to Write a Tree Expansion Listener and
How to Write a Tree-Will-Expand Listener.

Warning:
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 java.beans package.
Please see XMLEncoder.

The listener that's notified when a tree expands or collapses
a node.
For further documentation and examples see
How to Write a Tree Expansion Listener,
a section in The Java Tutorial.

Encapsulates information describing changes to a tree model, and
used to notify tree model listeners of the change.
For more information and examples see
How to Write a Tree Model Listener,
a section in The Java Tutorial.

Warning:
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 java.beans package.
Please see XMLEncoder.

Defines the interface for an object that listens
to changes in a TreeModel.
For further information and examples see
How to Write a Tree Model Listener,
a section in The Java Tutorial.

An event that characterizes a change in the current
selection.  The change is based on any number of paths.
TreeSelectionListeners will generally query the source of
the event for the new selected status of each potentially
changed row.

Warning:
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 java.beans package.
Please see XMLEncoder.

The listener that's notified when the selection in a TreeSelectionModel
changes.
For more information and examples see
How to Write a Tree Selection Listener,
a section in The Java Tutorial.

The listener that's notified when a tree expands or collapses
a node.
For further information and examples see
How to Write a Tree-Will-Expand Listener,
a section in The Java Tutorial.

An event indicating that an operation which can be undone has occurred.

Warning:
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 java.beans package.
Please see XMLEncoder.

Interface implemented by a class interested in hearing about
undoable operations.

FileFilter is an abstract class used by JFileChooser
for filtering the set of files shown to the user. See
FileNameExtensionFilter for an implementation that filters using
the file name extension.

A FileFilter
can be set on a JFileChooser to
keep unwanted files from appearing in the directory listing.
For an example implementation of a simple file filter, see
yourJDK/demo/jfc/FileChooserDemo/ExampleFileFilter.java.
For more information and examples see
How to Use File Choosers,
a section in The Java Tutorial.

An implementation of FileFilter that filters using a
specified set of extensions. The extension for a file is the
portion of the file name after the last ".". Files whose name does
not contain a "." have no file name extension. File name extension
comparisons are case insensitive.

The following example creates a
FileNameExtensionFilter that will show jpg files:


FileFilter filter = new FileNameExtensionFilter("JPEG file", "jpg", "jpeg");
JFileChooser fileChooser = ...;
fileChooser.addChoosableFileFilter(filter);

FileSystemView is JFileChooser's gateway to the
file system. Since the JDK1.1 File API doesn't allow
access to such information as root partitions, file type
information, or hidden file bits, this class is designed
to intuit as much OS-specific file system information as
possible.



Java Licensees may want to provide a different implementation of
FileSystemView to better handle a given operating system.

FileView defines an abstract class that can be implemented
to provide the filechooser with UI information for a File.
Each L&F JFileChooserUI object implements this
class to pass back the correct icons and type descriptions specific to
that L&F. For example, the Microsoft Windows L&F returns the
generic Windows icons for directories and generic files.
Additionally, you may want to provide your own FileView to
JFileChooser to return different icons or additional
information using JFileChooser.setFileView(javax.swing.filechooser.FileView).



JFileChooser first looks to see if there is a user defined
FileView, if there is, it gets type information from
there first. If FileView returns null for
any method, JFileChooser then uses the L&F specific
view to get the information.
So, for example, if you provide a FileView class that
returns an Icon for JPG files, and returns null
icons for all other files, the UI's FileView will provide
default icons for all other files.



For an example implementation of a simple file view, see
yourJDK/demo/jfc/FileChooserDemo/ExampleFileView.java.
For more information and examples see
How to Use File Choosers,
a section in The Java Tutorial.

This class has been obsoleted by the 1.4 focus APIs. While client code may
still use this class, developers are strongly encouraged to use
java.awt.KeyboardFocusManager and
java.awt.DefaultKeyboardFocusManager instead.

Please see

How to Use the Focus Subsystem,
a section in The Java Tutorial, and the
Focus Specification
for more information.

An image filter that "disables" an image by turning
it into a grayscale image, and brightening the pixels
in the image. Used by buttons to create an image for
a disabled button.

GroupLayout is a LayoutManager that hierarchically
groups components in order to position them in a Container.
GroupLayout is intended for use by builders, but may be
hand-coded as well.
Grouping is done by instances of the Group class. GroupLayout supports two types of groups. A sequential group
positions its child elements sequentially, one after another. A
parallel group aligns its child elements in one of four ways.

Each group may contain any number of elements, where an element is
a Group, Component, or gap. A gap can be thought
of as an invisible component with a minimum, preferred and maximum
size. In addition GroupLayout supports a preferred gap,
whose value comes from LayoutStyle.

Elements are similar to a spring. Each element has a range as
specified by a minimum, preferred and maximum.  Gaps have either a
developer-specified range, or a range determined by LayoutStyle. The range for Components is determined from
the Component's getMinimumSize, getPreferredSize and getMaximumSize methods. In addition,
when adding Components you may specify a particular range
to use instead of that from the component. The range for a Group is determined by the type of group. A ParallelGroup's
range is the maximum of the ranges of its elements. A SequentialGroup's range is the sum of the ranges of its elements.

GroupLayout treats each axis independently.  That is, there
is a group representing the horizontal axis, and a group
representing the vertical axis.  The horizontal group is
responsible for determining the minimum, preferred and maximum size
along the horizontal axis as well as setting the x and width of the
components contained in it. The vertical group is responsible for
determining the minimum, preferred and maximum size along the
vertical axis as well as setting the y and height of the
components contained in it. Each Component must exist in both
a horizontal and vertical group, otherwise an IllegalStateException
is thrown during layout, or when the minimum, preferred or
maximum size is requested.

The following diagram shows a sequential group along the horizontal
axis. The sequential group contains three components. A parallel group
was used along the vertical axis.



To reinforce that each axis is treated independently the diagram shows
the range of each group and element along each axis. The
range of each component has been projected onto the axes,
and the groups are rendered in blue (horizontal) and red (vertical).
For readability there is a gap between each of the elements in the
sequential group.

The sequential group along the horizontal axis is rendered as a solid
blue line. Notice the sequential group is the sum of the children elements
it contains.

Along the vertical axis the parallel group is the maximum of the height
of each of the components. As all three components have the same height,
the parallel group has the same height.

The following diagram shows the same three components, but with the
parallel group along the horizontal axis and the sequential group along
the vertical axis.




As c1 is the largest of the three components, the parallel
group is sized to c1. As c2 and c3 are smaller
than c1 they are aligned based on the alignment specified
for the component (if specified) or the default alignment of the
parallel group. In the diagram c2 and c3 were created
with an alignment of LEADING. If the component orientation were
right-to-left then c2 and c3 would be positioned on
the opposite side.

The following diagram shows a sequential group along both the horizontal
and vertical axis.



GroupLayout provides the ability to insert gaps between
Components. The size of the gap is determined by an
instance of LayoutStyle. This may be turned on using the
setAutoCreateGaps method.  Similarly, you may use
the setAutoCreateContainerGaps method to insert gaps
between components that touch the edge of the parent container and the
container.

The following builds a panel consisting of two labels in
one column, followed by two textfields in the next column:


  JComponent panel = ...;
  GroupLayout layout = new GroupLayout(panel);
  panel.setLayout(layout);

  // Turn on automatically adding gaps between components
  layout.setAutoCreateGaps(true);

  // Turn on automatically creating gaps between components that touch
  // the edge of the container and the container.
  layout.setAutoCreateContainerGaps(true);

  // Create a sequential group for the horizontal axis.

  GroupLayout.SequentialGroup hGroup = layout.createSequentialGroup();

  // The sequential group in turn contains two parallel groups.
  // One parallel group contains the labels, the other the text fields.
  // Putting the labels in a parallel group along the horizontal axis
  // positions them at the same x location.
  //
  // Variable indentation is used to reinforce the level of grouping.
  hGroup.addGroup(layout.createParallelGroup().
           addComponent(label1).addComponent(label2));
  hGroup.addGroup(layout.createParallelGroup().
           addComponent(tf1).addComponent(tf2));
  layout.setHorizontalGroup(hGroup);

  // Create a sequential group for the vertical axis.
  GroupLayout.SequentialGroup vGroup = layout.createSequentialGroup();

  // The sequential group contains two parallel groups that align
  // the contents along the baseline. The first parallel group contains
  // the first label and text field, and the second parallel group contains
  // the second label and text field. By using a sequential group
  // the labels and text fields are positioned vertically after one another.
  vGroup.addGroup(layout.createParallelGroup(Alignment.BASELINE).
           addComponent(label1).addComponent(tf1));
  vGroup.addGroup(layout.createParallelGroup(Alignment.BASELINE).
           addComponent(label2).addComponent(tf2));
  layout.setVerticalGroup(vGroup);

When run the following is produced.



This layout consists of the following.
The horizontal axis consists of a sequential group containing two
        parallel groups.  The first parallel group contains the labels,
        and the second parallel group contains the text fields.
    The vertical axis consists of a sequential group
        containing two parallel groups.  The parallel groups are configured
        to align their components along the baseline. The first parallel
        group contains the first label and first text field, and
        the second group consists of the second label and second
        text field.

There are a couple of things to notice in this code:

  You need not explicitly add the components to the container; this
      is indirectly done by using one of the add methods of
      Group.
  The various add methods return
      the caller.  This allows for easy chaining of invocations.  For
      example, group.addComponent(label1).addComponent(label2); is
      equivalent to
      group.addComponent(label1); group.addComponent(label2);.
  There are no public constructors for Groups; instead
      use the create methods of GroupLayout.

A small fixed size picture, typically used to decorate components.

An implementation of the Icon interface that paints Icons
from Images. Images that are created from a URL, filename or byte array
are preloaded using MediaTracker to monitor the loaded state
of the image.


For further information and examples of using image icons, see
How to Use Icons
in The Java Tutorial.


Warning:
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 java.beans package.
Please see XMLEncoder.

InputMap provides a binding between an input event
(currently only KeyStrokes are used)
and an Object. InputMaps
are usually used with an ActionMap,
to determine an Action to perform
when a key is pressed.
An InputMap can have a parent
that is searched for bindings not defined in the InputMap.
As with ActionMap if you create a cycle, eg:


  InputMap am = new InputMap();
  InputMap bm = new InputMap():
  am.setParent(bm);
  bm.setParent(am);
some of the methods will cause a StackOverflowError to be thrown.

    JTextField tf2 = new JTextField ("TextField2");
    getContentPane().add (tf2, BorderLayout.SOUTH);

    WindowListener l = new WindowAdapter() {
        public void windowClosing(WindowEvent e) {
            System.exit(0);
        }
    };
    addWindowListener(l);
}

class PassVerifier extends InputVerifier {
    public boolean verify(JComponent input) {
        JTextField tf = (JTextField) input;
        return "pass".equals(tf.getText());
    }
}

public static void main(String[] args) {
    Frame f = new VerifierTest();
    f.pack();
    f.setVisible(true);
}

The purpose of this class is to help clients support smooth focus
navigation through GUIs with text fields. Such GUIs often need
to ensure that the text entered by the user is valid (for example,
that it's in
the proper format) before allowing the user to navigate out of
the text field. To do this, clients create a subclass of
InputVerifier and, using JComponent's
setInputVerifier method,
attach an instance of their subclass to the JComponent whose input they
want to validate. Before focus is transfered to another Swing component
that requests it, the input verifier's shouldYieldFocus method is
called.  Focus is transfered only if that method returns true.

The following example has two text fields, with the first one expecting
the string "pass" to be entered by the user. If that string is entered in
the first text field, then the user can advance to the second text field
either by clicking in it or by pressing TAB. However, if another string
is entered in the first text field, then the user will be unable to
transfer focus to the second text field.



import java.awt.*;
import java.util.*;
import java.awt.event.*;
import javax.swing.*;

// This program demonstrates the use of the Swing InputVerifier class.
// It creates two text fields; the first of the text fields expects the
// string "pass" as input, and will allow focus to advance out of it
// only after that string is typed in by the user.

public class VerifierTest extends JFrame {
    public VerifierTest() {
        JTextField tf1 = new JTextField ("Type \"pass\" here");
        getContentPane().add (tf1, BorderLayout.NORTH);
        tf1.setInputVerifier(new PassVerifier());

        JTextField tf2 = new JTextField ("TextField2");
        getContentPane().add (tf2, BorderLayout.SOUTH);

        WindowListener l = new WindowAdapter() {
            public void windowClosing(WindowEvent e) {
                System.exit(0);
            }
        };
        addWindowListener(l);
    }

    class PassVerifier extends InputVerifier {
        public boolean verify(JComponent input) {
            JTextField tf = (JTextField) input;
            return "pass".equals(tf.getText());
        }
    }

    public static void main(String[] args) {
        Frame f = new VerifierTest();
        f.pack();
        f.setVisible(true);
    }
}

A FocusTraversalPolicy which can optionally provide an algorithm for
determining a JInternalFrame's initial Component. The initial Component is
the first to receive focus when the JInternalFrame is first selected. By
default, this is the same as the JInternalFrame's default Component to
focus.

  applet.add(child);

An extended version of java.applet.Applet that adds support for
the JFC/Swing component architecture.
You can find task-oriented documentation about using JApplet
in The Java Tutorial,
in the section
How to Make Applets.

The JApplet class is slightly incompatible with
java.applet.Applet.  JApplet contains a
JRootPane as its only child.  The contentPane
should be the parent of any children of the JApplet.
As a convenience, the add, remove, and setLayout
methods of this class are overridden, so that they delegate calls
to the corresponding methods of the ContentPane.
For example, you can add a child component to an applet as follows:


      applet.add(child);

And the child will be added to the contentPane.
The contentPane will always be non-null.
Attempting to set it to null will cause the
JApplet to throw an exception. The default
contentPane will have a BorderLayout
manager set on it.
Refer to RootPaneContainer
for details on adding, removing and setting the LayoutManager
of a JApplet.

Please see the JRootPane documentation for a
complete description of the contentPane, glassPane,
and layeredPane properties.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

An implementation of a "push" button.

Buttons can be configured, and to some degree controlled, by
Actions.  Using an
Action with a button has many benefits beyond directly
configuring a button.  Refer to
Swing Components Supporting Action for more
details, and you can find more information in How
to Use Actions, a section in The Java Tutorial.

See How to Use Buttons, Check Boxes, and Radio Buttons
in The Java Tutorial
for information and examples of using buttons.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

An implementation of a check box -- an item that can be selected or
deselected, and which displays its state to the user.
By convention, any number of check boxes in a group can be selected.
See How to Use Buttons, Check Boxes, and Radio Buttons
in The Java Tutorial
for examples and information on using check boxes.

Buttons can be configured, and to some degree controlled, by
Actions.  Using an
Action with a button has many benefits beyond directly
configuring a button.  Refer to
Swing Components Supporting Action for more
details, and you can find more information in How
to Use Actions, a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A menu item that can be selected or deselected. If selected, the menu
item typically appears with a checkmark next to it. If unselected or
deselected, the menu item appears without a checkmark. Like a regular
menu item, a check box menu item can have either text or a graphic
icon associated with it, or both.

Either isSelected/setSelected or
getState/setState can be used
to determine/specify the menu item's selection state. The
preferred methods are isSelected and
setSelected, which work for all menus and buttons.
The getState and setState methods exist for
compatibility with other component sets.

Menu items can be configured, and to some degree controlled, by
Actions.  Using an
Action with a menu item has many benefits beyond directly
configuring a menu item.  Refer to
Swing Components Supporting Action for more
details, and you can find more information in How
to Use Actions, a section in The Java Tutorial.

For further information and examples of using check box menu items,
see How to Use Menus,
a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

JColorChooser provides a pane of controls designed to allow
a user to manipulate and select a color.
For information about using color choosers, see
How to Use Color Choosers,
a section in The Java Tutorial.



This class provides three levels of API:

A static convenience method which shows a modal color-chooser
dialog and returns the color selected by the user.
A static convenience method for creating a color-chooser dialog
where ActionListeners can be specified to be invoked when
the user presses one of the dialog buttons.
The ability to create instances of JColorChooser panes
directly (within any container). PropertyChange listeners
can be added to detect when the current "color" property changes.


Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A component that combines a button or editable field and a drop-down list.
The user can select a value from the drop-down list, which appears at the
user's request. If you make the combo box editable, then the combo box
includes an editable field into which the user can type a value.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.


See How to Use Combo Boxes
in The Java Tutorial
for further information.

The interface that defines a KeySelectionManager.
To qualify as a KeySelectionManager,
the class needs to implement the method
that identifies the list index given a character and the
combo box data model.

The base class for all Swing components except top-level containers.
To use a component that inherits from JComponent,
you must place the component in a containment hierarchy
whose root is a top-level Swing container.
Top-level Swing containers --
such as JFrame, JDialog,
and JApplet --
are specialized components
that provide a place for other Swing components to paint themselves.
For an explanation of containment hierarchies, see
Swing Components and the Containment Hierarchy,
a section in The Java Tutorial.


The JComponent class provides:

The base class for both standard and custom components
    that use the Swing architecture.
A "pluggable look and feel" (L&F) that can be specified by the
    programmer or (optionally) selected by the user at runtime.
    The look and feel for each component is provided by a
    UI delegate -- an object that descends from
    ComponentUI.
    See How
    to Set the Look and Feel
    in The Java Tutorial
    for more information.
Comprehensive keystroke handling.
    See the document How to Use Key Bindings,
    an article in The Java Tutorial,
    for more information.
Support for tool tips --
    short descriptions that pop up when the cursor lingers
    over a component.
    See How
    to Use Tool Tips
    in The Java Tutorial
    for more information.
Support for accessibility.
    JComponent contains all of the methods in the
    Accessible interface,
    but it doesn't actually implement the interface.  That is the
    responsibility of the individual classes
    that extend JComponent.
Support for component-specific properties.
    With the putClientProperty(java.lang.Object, java.lang.Object)
    and getClientProperty(java.lang.Object) methods,
    you can associate name-object pairs
    with any object that descends from JComponent.
An infrastructure for painting
    that includes double buffering and support for borders.
    For more information see Painting and
How
    to Use Borders,
    both of which are sections in The Java Tutorial.

For more information on these subjects, see the
Swing package description
and The Java Tutorial section
The JComponent Class.

JComponent and its subclasses document default values
for certain properties.  For example, JTable documents the
default row height as 16.  Each JComponent subclass
that has a ComponentUI will create the
ComponentUI as part of its constructor.  In order
to provide a particular look and feel each
ComponentUI may set properties back on the
JComponent that created it.  For example, a custom
look and feel may require JTables to have a row
height of 24. The documented defaults are the value of a property
BEFORE the ComponentUI has been installed.  If you
need a specific value for a particular property you should
explicitly set it.

In release 1.4, the focus subsystem was rearchitected.
For more information, see

How to Use the Focus Subsystem,
a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A container used to create a multiple-document interface or a virtual desktop.
You create JInternalFrame objects and add them to the
JDesktopPane. JDesktopPane extends
JLayeredPane to manage the potentially overlapping internal
frames. It also maintains a reference to an instance of
DesktopManager that is set by the UI
class for the current look and feel (L&F).  Note that JDesktopPane
does not support borders.

This class is normally used as the parent of JInternalFrames
to provide a pluggable DesktopManager object to the
JInternalFrames. The installUI of the
L&F specific implementation is responsible for setting the
desktopManager variable appropriately.
When the parent of a JInternalFrame is a JDesktopPane,
it should delegate most of its behavior to the desktopManager
(closing, resizing, etc).

For further documentation and examples see
How to Use Internal Frames,
a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

  dialog.add(child);

The main class for creating a dialog window. You can use this class
to create a custom dialog, or invoke the many class methods
in JOptionPane to create a variety of standard dialogs.
For information about creating dialogs, see
The Java Tutorial section
How
to Make Dialogs.



The JDialog component contains a JRootPane
as its only child.
The contentPane should be the parent of any children of the
JDialog.
As a convenience, the add, remove, and setLayout
methods of this class are overridden, so that they delegate calls
to the corresponding methods of the ContentPane.
For example, you can add a child component to a dialog as follows:


      dialog.add(child);
And the child will be added to the contentPane.
The contentPane is always non-null.
Attempting to set it to null generates an exception.
The default contentPane has a BorderLayout
manager set on it.
Refer to RootPaneContainer
for details on adding, removing and setting the LayoutManager
of a JDialog.

Please see the JRootPane documentation for a complete
description of the contentPane, glassPane,
and layeredPane components.

In a multi-screen environment, you can create a JDialog
on a different screen device than its owner.  See Frame for
more information.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

class Hyperactive implements HyperlinkListener {

    public void hyperlinkUpdate(HyperlinkEvent e) {
        if (e.getEventType() == HyperlinkEvent.EventType.ACTIVATED) {
            JEditorPane pane = (JEditorPane) e.getSource();
            if (e instanceof HTMLFrameHyperlinkEvent) {
                HTMLFrameHyperlinkEvent  evt = (HTMLFrameHyperlinkEvent)e;
                HTMLDocument doc = (HTMLDocument)pane.getDocument();
                doc.processHTMLFrameHyperlinkEvent(evt);
            } else {
                try {
                    pane.setPage(e.getURL());
                } catch (Throwable t) {
                    t.printStackTrace();
                }
            }
        }
    }
}

A text component to edit various kinds of content.
You can find how-to information and examples of using editor panes in
Using Text Components,
a section in The Java Tutorial.


This component uses implementations of the
EditorKit to accomplish its behavior. It effectively
morphs into the proper kind of text editor for the kind
of content it is given.  The content type that editor is bound
to at any given time is determined by the EditorKit currently
installed.  If the content is set to a new URL, its type is used
to determine the EditorKit that should be used to
load the content.

By default, the following types of content are known:

text/plain
Plain text, which is the default the type given isn't
recognized.  The kit used in this case is an extension of
DefaultEditorKit that produces a wrapped plain text view.
text/html
HTML text.  The kit used in this case is the class
javax.swing.text.html.HTMLEditorKit
which provides HTML 3.2 support.
text/rtf
RTF text.  The kit used in this case is the class
javax.swing.text.rtf.RTFEditorKit
which provides a limited support of the Rich Text Format.


There are several ways to load content into this component.


The setText method can be used to initialize
the component from a string.  In this case the current
EditorKit will be used, and the content type will be
expected to be of this type.

The read method can be used to initialize the
component from a Reader.  Note that if the content type is HTML,
relative references (e.g. for things like images) can't be resolved
unless the <base> tag is used or the Base property
on HTMLDocument is set.
In this case the current EditorKit will be used,
and the content type will be expected to be of this type.

The setPage method can be used to initialize
the component from a URL.  In this case, the content type will be
determined from the URL, and the registered EditorKit
for that content type will be set.


Some kinds of content may provide hyperlink support by generating
hyperlink events.  The HTML EditorKit will generate
hyperlink events if the JEditorPane is not editable
(JEditorPane.setEditable(false); has been called).
If HTML frames are embedded in the document, the typical response would be
to change a portion of the current document.  The following code
fragment is a possible hyperlink listener implementation, that treats
HTML frame events specially, and simply displays any other activated
hyperlinks.


    class Hyperactive implements HyperlinkListener {

        public void hyperlinkUpdate(HyperlinkEvent e) {
            if (e.getEventType() == HyperlinkEvent.EventType.ACTIVATED) {
                JEditorPane pane = (JEditorPane) e.getSource();
                if (e instanceof HTMLFrameHyperlinkEvent) {
                    HTMLFrameHyperlinkEvent  evt = (HTMLFrameHyperlinkEvent)e;
                    HTMLDocument doc = (HTMLDocument)pane.getDocument();
                    doc.processHTMLFrameHyperlinkEvent(evt);
                } else {
                    try {
                        pane.setPage(e.getURL());
                    } catch (Throwable t) {
                        t.printStackTrace();
                    }
                }
            }
        }
    }

For information on customizing how text/html is rendered please see
W3C_LENGTH_UNITS and HONOR_DISPLAY_PROPERTIES

Culturally dependent information in some documents is handled through
a mechanism called character encoding.  Character encoding is an
unambiguous mapping of the members of a character set (letters, ideographs,
digits, symbols, or control functions) to specific numeric code values. It
represents the way the file is stored. Example character encodings are
ISO-8859-1, ISO-8859-5, Shift-jis, Euc-jp, and UTF-8. When the file is
passed to an user agent (JEditorPane) it is converted to
the document character set (ISO-10646 aka Unicode).

There are multiple ways to get a character set mapping to happen
with JEditorPane.


One way is to specify the character set as a parameter of the MIME
type.  This will be established by a call to the
setContentType method.  If the content
is loaded by the setPage method the content
type will have been set according to the specification of the URL.
It the file is loaded directly, the content type would be expected to
have been set prior to loading.

Another way the character set can be specified is in the document itself.
This requires reading the document prior to determining the character set
that is desired.  To handle this, it is expected that the
EditorKit.read operation throw a
ChangedCharSetException which will
be caught.  The read is then restarted with a new Reader that uses
the character set specified in the ChangedCharSetException
(which is an IOException).



Newlines

For a discussion on how newlines are handled, see
DefaultEditorKit.



Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

JFileChooser provides a simple mechanism for the user to
choose a file.
For information about using JFileChooser, see
How to Use File Choosers,
a section in The Java Tutorial.



The following code pops up a file chooser for the user's home directory that
sees only .jpg and .gif images:


   JFileChooser chooser = new JFileChooser();
   FileNameExtensionFilter filter = new FileNameExtensionFilter(
       "JPG & GIF Images", "jpg", "gif");
   chooser.setFileFilter(filter);
   int returnVal = chooser.showOpenDialog(parent);
   if(returnVal == JFileChooser.APPROVE_OPTION) {
      System.out.println("You chose to open this file: "
           chooser.getSelectedFile().getName());
   }

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

JFormattedTextField extends JTextField adding
support for formatting arbitrary values, as well as retrieving a particular
object once the user has edited the text. The following illustrates
configuring a JFormattedTextField to edit dates:


  JFormattedTextField ftf = new JFormattedTextField();
  ftf.setValue(new Date());

Once a JFormattedTextField has been created, you can
listen for editing changes by way of adding
a PropertyChangeListener and listening for
PropertyChangeEvents with the property name value.

JFormattedTextField allows
configuring what action should be taken when focus is lost. The possible
configurations are:

ValueDescription
JFormattedTextField.REVERT
           Revert the display to match that of getValue,
               possibly losing the current edit.
       JFormattedTextField.COMMIT
           Commits the current value. If the value being edited
               isn't considered a legal value by the
               AbstractFormatter that is, a
               ParseException is thrown, then the value
               will not change, and then edited value will persist.
       JFormattedTextField.COMMIT_OR_REVERT
           Similar to COMMIT, but if the value isn't
               legal, behave like REVERT.
       JFormattedTextField.PERSIST
           Do nothing, don't obtain a new
               AbstractFormatter, and don't update the value.

The default is JFormattedTextField.COMMIT_OR_REVERT,
refer to setFocusLostBehavior(int) for more information on this.

JFormattedTextField allows the focus to leave, even if
the currently edited value is invalid. To lock the focus down while the
JFormattedTextField is an invalid edit state
you can attach an InputVerifier. The following code snippet
shows a potential implementation of such an InputVerifier:


public class FormattedTextFieldVerifier extends InputVerifier {
    public boolean verify(JComponent input) {
        if (input instanceof JFormattedTextField) {
            JFormattedTextField ftf = (JFormattedTextField)input;
            AbstractFormatter formatter = ftf.getFormatter();
            if (formatter != null) {
                String text = ftf.getText();
                try {
                     formatter.stringToValue(text);
                     return true;
                 } catch (ParseException pe) {
                     return false;
                 }
             }
         }
         return true;
     }
     public boolean shouldYieldFocus(JComponent input) {
         return verify(input);
     }
 }

Alternatively, you could invoke commitEdit, which would also
commit the value.

JFormattedTextField does not do the formatting it self,
rather formatting is done through an instance of
JFormattedTextField.AbstractFormatter which is obtained from
an instance of JFormattedTextField.AbstractFormatterFactory.
Instances of JFormattedTextField.AbstractFormatter are
notified when they become active by way of the
install method, at which point the
JFormattedTextField.AbstractFormatter can install whatever
it needs to, typically a DocumentFilter. Similarly when
JFormattedTextField no longer
needs the AbstractFormatter, it will invoke
uninstall.

JFormattedTextField typically
queries the AbstractFormatterFactory for an
AbstractFormat when it gains or loses focus. Although this
can change based on the focus lost policy. If the focus lost
policy is JFormattedTextField.PERSIST
and the JFormattedTextField has been edited, the
AbstractFormatterFactory will not be queried until the
value has been committed. Similarly if the focus lost policy is
JFormattedTextField.COMMIT and an exception
is thrown from stringToValue, the
AbstractFormatterFactory will not be queried when focus is
lost or gained.

JFormattedTextField.AbstractFormatter
is also responsible for determining when values are committed to
the JFormattedTextField. Some
JFormattedTextField.AbstractFormatters will make new values
available on every edit, and others will never commit the value. You can
force the current value to be obtained
from the current JFormattedTextField.AbstractFormatter
by way of invoking commitEdit. commitEdit will
be invoked whenever return is pressed in the
JFormattedTextField.

If an AbstractFormatterFactory has not been explicitly
set, one will be set based on the Class of the value type after
setValue has been invoked (assuming value is non-null).
For example, in the following code an appropriate
AbstractFormatterFactory and AbstractFormatter
will be created to handle formatting of numbers:


  JFormattedTextField tf = new JFormattedTextField();
  tf.setValue(100);

Warning: As the AbstractFormatter will
typically install a DocumentFilter on the
Document, and a NavigationFilter on the
JFormattedTextField you should not install your own. If you do,
you are likely to see odd behavior in that the editing policy of the
AbstractFormatter will not be enforced.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

Instances of AbstractFormatter are used by
JFormattedTextField to handle the conversion both
from an Object to a String, and back from a String to an Object.
AbstractFormatters can also enforce editing policies,
or navigation policies, or manipulate the
JFormattedTextField in any way it sees fit to
enforce the desired policy.

An AbstractFormatter can only be active in
one JFormattedTextField at a time.
JFormattedTextField invokes
install when it is ready to use it followed
by uninstall when done. Subclasses
that wish to install additional state should override
install and message super appropriately.

Subclasses must override the conversion methods
stringToValue and valueToString. Optionally
they can override getActions,
getNavigationFilter and getDocumentFilter
to restrict the JFormattedTextField in a particular
way.

Subclasses that allow the JFormattedTextField to be in
a temporarily invalid state should invoke setEditValid
at the appropriate times.

Instances of AbstractFormatterFactory are used by
JFormattedTextField to obtain instances of
AbstractFormatter which in turn are used to format values.
AbstractFormatterFactory can return different
AbstractFormatters based on the state of the
JFormattedTextField, perhaps returning different
AbstractFormatters when the
JFormattedTextField has focus vs when it
doesn't have focus.

  frame.add(child);

An extended version of java.awt.Frame that adds support for
the JFC/Swing component architecture.
You can find task-oriented documentation about using JFrame
in The Java Tutorial, in the section
How to Make Frames.


The JFrame class is slightly incompatible with Frame.
Like all other JFC/Swing top-level containers,
a JFrame contains a JRootPane as its only child.
The content pane provided by the root pane should,
as a rule, contain
all the non-menu components displayed by the JFrame.
This is different from the AWT Frame case.
As a convenience, the add, remove, and setLayout
methods of this class are overridden, so that they delegate calls
to the corresponding methods of the ContentPane.
For example, you can add a child component to a frame as follows:


      frame.add(child);
And the child will be added to the contentPane.
The content pane will
always be non-null. Attempting to set it to null will cause the JFrame
to throw an exception. The default content pane will have a BorderLayout
manager set on it.
Refer to RootPaneContainer
for details on adding, removing and setting the LayoutManager
of a JFrame.

Unlike a Frame, a JFrame has some notion of how to
respond when the user attempts to close the window. The default behavior
is to simply hide the JFrame when the user closes the window. To change the
default behavior, you invoke the method
setDefaultCloseOperation(int).
To make the JFrame behave the same as a Frame
instance, use
setDefaultCloseOperation(WindowConstants.DO_NOTHING_ON_CLOSE).

For more information on content panes
and other features that root panes provide,
see Using Top-Level Containers in The Java Tutorial.

In a multi-screen environment, you can create a JFrame
on a different screen device.  See Frame for more
information.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

  internalFrame.add(child);

A lightweight object that provides many of the features of
a native frame, including dragging, closing, becoming an icon,
resizing, title display, and support for a menu bar.
For task-oriented documentation and examples of using internal frames,
see How to Use Internal Frames,
a section in The Java Tutorial.



Generally,
you add JInternalFrames to a JDesktopPane. The UI
delegates the look-and-feel-specific actions to the
DesktopManager
object maintained by the JDesktopPane.

The JInternalFrame content pane
is where you add child components.
As a convenience, the add, remove, and setLayout
methods of this class are overridden, so that they delegate calls
to the corresponding methods of the ContentPane.
For example, you can add a child component to an internal frame as follows:


      internalFrame.add(child);
And the child will be added to the contentPane.
The content pane is actually managed by an instance of
JRootPane,
which also manages a layout pane, glass pane, and
optional menu bar for the internal frame. Please see the
JRootPane
documentation for a complete description of these components.
Refer to RootPaneContainer
for details on adding, removing and setting the LayoutManager
of a JInternalFrame.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

This component represents an iconified version of a
JInternalFrame.
This API should NOT BE USED by Swing applications, as it will go
away in future versions of Swing as its functionality is moved into
JInternalFrame.  This class is public only so that
UI objects can display a desktop icon.  If an application
wants to display a desktop icon, it should create a
JInternalFrame instance and iconify it.

Warning:
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 java.beans package.
Please see XMLEncoder.

A display area for a short text string or an image,
or both.
A label does not react to input events.
As a result, it cannot get the keyboard focus.
A label can, however, display a keyboard alternative
as a convenience for a nearby component
that has a keyboard alternative but can't display it.

A JLabel object can display
either text, an image, or both.
You can specify where in the label's display area
the label's contents are aligned
by setting the vertical and horizontal alignment.
By default, labels are vertically centered
in their display area.
Text-only labels are leading edge aligned, by default;
image-only labels are horizontally centered, by default.

You can also specify the position of the text
relative to the image.
By default, text is on the trailing edge of the image,
with the text and image vertically aligned.

A label's leading and trailing edge are determined from the value of its
ComponentOrientation property.  At present, the default
ComponentOrientation setting maps the leading edge to left and the trailing
edge to right.


Finally, you can use the setIconTextGap method
to specify how many pixels
should appear between the text and the image.
The default is 4 pixels.

See How to Use Labels
in The Java Tutorial
for further documentation.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

private static JLayer<JComponent> createLayer() {
    // This custom layerUI will fill the layer with translucent green
    // and print out all mouseMotion events generated within its borders
    LayerUI<JComponent> layerUI = new LayerUI<JComponent>() {

        public void paint(Graphics g, JComponent c) {
            // paint the layer as is
            super.paint(g, c);
            // fill it with the translucent green
            g.setColor(new Color(0, 128, 0, 128));
            g.fillRect(0, 0, c.getWidth(), c.getHeight());
        }

        public void installUI(JComponent c) {
            super.installUI(c);
            // enable mouse motion events for the layer's subcomponents
            ((JLayer) c).setLayerEventMask(AWTEvent.MOUSE_MOTION_EVENT_MASK);
        }

        public void uninstallUI(JComponent c) {
            super.uninstallUI(c);
            // reset the layer event mask
            ((JLayer) c).setLayerEventMask(0);
        }

        // overridden method which catches MouseMotion events
        public void eventDispatched(AWTEvent e, JLayer<? extends JComponent> l) {
            System.out.println("AWTEvent detected: "  e);
        }
    };
    // create a component to be decorated with the layer
    JPanel panel = new JPanel();
    panel.add(new JButton("JButton"));

    // create the layer for the panel using our custom layerUI
    return new JLayer<JComponent>(panel, layerUI);
}

private static void createAndShowGUI() {
    final JFrame frame = new JFrame();
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

    // work with the layer as with any other Swing component
    frame.add(createLayer());

    frame.setSize(200, 200);
    frame.setLocationRelativeTo(null);
    frame.setVisible(true);
}

public static void main(String[] args) throws Exception {
    SwingUtilities.invokeAndWait(new Runnable() {
        public void run() {
            createAndShowGUI();
        }
    });
}

JLayer is a universal decorator for Swing components
which enables you to implement various advanced painting effects as well as
receive notifications of all AWTEvents generated within its borders.

JLayer delegates the handling of painting and input events to a
LayerUI object, which performs the actual decoration.

The custom painting implemented in the LayerUI and events notification
work for the JLayer itself and all its subcomponents.
This combination enables you to enrich existing components
by adding new advanced functionality such as temporary locking of a hierarchy,
data tips for compound components, enhanced mouse scrolling etc and so on.

JLayer is a good solution if you only need to do custom painting
over compound component or catch input events from its subcomponents.


import javax.swing.*;
import javax.swing.plaf.LayerUI;
import java.awt.*;

public class JLayerSample {

    private static JLayer<JComponent> createLayer() {
        // This custom layerUI will fill the layer with translucent green
        // and print out all mouseMotion events generated within its borders
        LayerUI<JComponent> layerUI = new LayerUI<JComponent>() {

            public void paint(Graphics g, JComponent c) {
                // paint the layer as is
                super.paint(g, c);
                // fill it with the translucent green
                g.setColor(new Color(0, 128, 0, 128));
                g.fillRect(0, 0, c.getWidth(), c.getHeight());
            }

            public void installUI(JComponent c) {
                super.installUI(c);
                // enable mouse motion events for the layer's subcomponents
                ((JLayer) c).setLayerEventMask(AWTEvent.MOUSE_MOTION_EVENT_MASK);
            }

            public void uninstallUI(JComponent c) {
                super.uninstallUI(c);
                // reset the layer event mask
                ((JLayer) c).setLayerEventMask(0);
            }

            // overridden method which catches MouseMotion events
            public void eventDispatched(AWTEvent e, JLayer<? extends JComponent> l) {
                System.out.println("AWTEvent detected: "  e);
            }
        };
        // create a component to be decorated with the layer
        JPanel panel = new JPanel();
        panel.add(new JButton("JButton"));

        // create the layer for the panel using our custom layerUI
        return new JLayer<JComponent>(panel, layerUI);
    }

    private static void createAndShowGUI() {
        final JFrame frame = new JFrame();
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);

        // work with the layer as with any other Swing component
        frame.add(createLayer());

        frame.setSize(200, 200);
        frame.setLocationRelativeTo(null);
        frame.setVisible(true);
    }

    public static void main(String[] args) throws Exception {
        SwingUtilities.invokeAndWait(new Runnable() {
            public void run() {
                createAndShowGUI();
            }
        });
    }
}

Note: JLayer doesn't support the following methods:

Container.add(java.awt.Component)
Container.add(String, java.awt.Component)
Container.add(java.awt.Component, int)
Container.add(java.awt.Component, Object)
Container.add(java.awt.Component, Object, int)

using any of of them will cause UnsupportedOperationException to be thrown,
to add a component to JLayer
use setView(Component) or setGlassPane(JPanel).

layeredPane.add(child, JLayeredPane.DEFAULT_LAYER);

layeredPaneParent.setLayer(child, 10)

  5a, 5b, 5c, 2a, 2b, 2c, 1a

  5a, 5b, 5c, 5x, 2a, 2b, 2c, 1a

  5a, 5b, 5z, 5c, 5x, 2a, 2b, 2c, 1a

  5a, 5b, 5z, 5c, 5x, 3a, 2a, 2b, 2c, 1a

JLayeredPane adds depth to a JFC/Swing container,
allowing components to overlap each other when needed.
An Integer object specifies each component's depth in the
container, where higher-numbered components sit "on top" of other
components.
For task-oriented documentation and examples of using layered panes see
How to Use a Layered Pane,
a section in The Java Tutorial.








For convenience, JLayeredPane divides the depth-range
into several different layers. Putting a component into one of those
layers makes it easy to ensure that components overlap properly,
without having to worry about specifying numbers for specific depths:

   DEFAULT_LAYER
        The standard layer, where most components go. This the bottommost
        layer.
   PALETTE_LAYER
        The palette layer sits over the default layer. Useful for floating
        toolbars and palettes, so they can be positioned above other components.
   MODAL_LAYER
        The layer used for modal dialogs. They will appear on top of any
        toolbars, palettes, or standard components in the container.
   POPUP_LAYER
        The popup layer displays above dialogs. That way, the popup windows
        associated with combo boxes, tooltips, and other help text will appear
        above the component, palette, or dialog that generated them.
   DRAG_LAYER
        When dragging a component, reassigning it to the drag layer ensures
        that it is positioned over every other component in the container. When
        finished dragging, it can be reassigned to its normal layer.

The JLayeredPane methods moveToFront(Component),
moveToBack(Component) and setPosition can be used
to reposition a component within its layer. The setLayer method
can also be used to change the component's current layer.

Details
JLayeredPane manages its list of children like
Container, but allows for the definition of a several
layers within itself. Children in the same layer are managed exactly
like the normal Container object,
with the added feature that when children components overlap, children
in higher layers display above the children in lower layers.

Each layer is a distinct integer number. The layer attribute can be set
on a Component by passing an Integer
object during the add call. For example:


    layeredPane.add(child, JLayeredPane.DEFAULT_LAYER);
or
    layeredPane.add(child, new Integer(10));
The layer attribute can also be set on a Component by calling

    layeredPaneParent.setLayer(child, 10)
on the JLayeredPane that is the parent of component. The layer
should be set before adding the child to the parent.

Higher number layers display above lower number layers. So, using
numbers for the layers and letters for individual components, a
representative list order would look like this:

      5a, 5b, 5c, 2a, 2b, 2c, 1a
where the leftmost components are closest to the top of the display.

A component can be moved to the top or bottom position within its
layer by calling moveToFront or moveToBack.

The position of a component within a layer can also be specified directly.
Valid positions range from 0 up to one less than the number of
components in that layer. A value of -1 indicates the bottommost
position. A value of 0 indicates the topmost position. Unlike layer
numbers, higher position values are lower in the display.

Note: This sequence (defined by java.awt.Container) is the reverse
of the layer numbering sequence. Usually though, you will use moveToFront,
moveToBack, and setLayer.

Here are some examples using the method add(Component, layer, position):
Calling add(5x, 5, -1) results in:

      5a, 5b, 5c, 5x, 2a, 2b, 2c, 1a

Calling add(5z, 5, 2) results in:

      5a, 5b, 5z, 5c, 5x, 2a, 2b, 2c, 1a

Calling add(3a, 3, 7) results in:

      5a, 5b, 5z, 5c, 5x, 3a, 2a, 2b, 2c, 1a

Using normal paint/event mechanics results in 1a appearing at the bottom
and 5a being above all other components.

Note: that these layers are simply a logical construct and LayoutManagers
will affect all child components of this container without regard for
layer settings.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

// This is the only method defined by ListCellRenderer.
// We just reconfigure the JLabel each time we're called.

public Component getListCellRendererComponent(
  JList<?> list,           // the list
  Object value,            // value to display
  int index,               // cell index
  boolean isSelected,      // is the cell selected
  boolean cellHasFocus)    // does the cell have focus
{
    String s = value.toString();
    setText(s);
    setIcon((s.length() > 10) ? longIcon : shortIcon);
    if (isSelected) {
        setBackground(list.getSelectionBackground());
        setForeground(list.getSelectionForeground());
    } else {
        setBackground(list.getBackground());
        setForeground(list.getForeground());
    }
    setEnabled(list.isEnabled());
    setFont(list.getFont());
    setOpaque(true);
    return this;
}

A component that displays a list of objects and allows the user to select
one or more items. A separate model, ListModel, maintains the
contents of the list.

It's easy to display an array or Vector of objects, using the JList
constructor that automatically builds a read-only ListModel instance
for you:


// Create a JList that displays strings from an array

String[] data = {"one", "two", "three", "four"};
JList<String> myList = new JList<String>(data);

// Create a JList that displays the superclasses of JList.class, by
// creating it with a Vector populated with this data

Vector<Class<?>> superClasses = new Vector<Class<?>>();
Class<JList> rootClass = javax.swing.JList.class;
for(Class<?> cls = rootClass; cls != null; cls = cls.getSuperclass()) {
    superClasses.addElement(cls);
}
JList<Class<?>> myList = new JList<Class<?>>(superClasses);

// The automatically created model is stored in JList's "model"
// property, which you can retrieve

ListModel<Class<?>> model = myList.getModel();
for(int i = 0; i < model.getSize(); i++) {
    System.out.println(model.getElementAt(i));
}

A ListModel can be supplied directly to a JList by way of a
constructor or the setModel method. The contents need not be static -
the number of items, and the values of items can change over time. A correct
ListModel implementation notifies the set of
javax.swing.event.ListDataListeners that have been added to it, each
time a change occurs. These changes are characterized by a
javax.swing.event.ListDataEvent, which identifies the range of list
indices that have been modified, added, or removed. JList's
ListUI is responsible for keeping the visual representation up to
date with changes, by listening to the model.

Simple, dynamic-content, JList applications can use the
DefaultListModel class to maintain list elements. This class
implements the ListModel interface and also provides a
java.util.Vector-like API. Applications that need a more
custom ListModel implementation may instead wish to subclass
AbstractListModel, which provides basic support for managing and
notifying listeners. For example, a read-only implementation of
AbstractListModel:


// This list model has about 2^16 elements.  Enjoy scrolling.

ListModel<String> bigData = new AbstractListModel<String>() {
    public int getSize() { return Short.MAX_VALUE; }
    public String getElementAt(int index) { return "Index "  index; }
};

The selection state of a JList is managed by another separate
model, an instance of ListSelectionModel. JList is
initialized with a selection model on construction, and also contains
methods to query or set this selection model. Additionally, JList
provides convenient methods for easily managing the selection. These methods,
such as setSelectedIndex and getSelectedValue, are cover
methods that take care of the details of interacting with the selection
model. By default, JList's selection model is configured to allow any
combination of items to be selected at a time; selection mode
MULTIPLE_INTERVAL_SELECTION. The selection mode can be changed
on the selection model directly, or via JList's cover method.
Responsibility for updating the selection model in response to user gestures
lies with the list's ListUI.

A correct ListSelectionModel implementation notifies the set of
javax.swing.event.ListSelectionListeners that have been added to it
each time a change to the selection occurs. These changes are characterized
by a javax.swing.event.ListSelectionEvent, which identifies the range
of the selection change.

The preferred way to listen for changes in list selection is to add
ListSelectionListeners directly to the JList. JList
then takes care of listening to the the selection model and notifying your
listeners of change.

Responsibility for listening to selection changes in order to keep the list's
visual representation up to date lies with the list's ListUI.


Painting of cells in a JList is handled by a delegate called a
cell renderer, installed on the list as the cellRenderer property.
The renderer provides a java.awt.Component that is used
like a "rubber stamp" to paint the cells. Each time a cell needs to be
painted, the list's ListUI asks the cell renderer for the component,
moves it into place, and has it paint the contents of the cell by way of its
paint method. A default cell renderer, which uses a JLabel
component to render, is installed by the lists's ListUI. You can
substitute your own renderer using code like this:


 // Display an icon and a string for each object in the list.

class MyCellRenderer extends JLabel implements ListCellRenderer<Object> {
    final static ImageIcon longIcon = new ImageIcon("long.gif");
    final static ImageIcon shortIcon = new ImageIcon("short.gif");

    // This is the only method defined by ListCellRenderer.
    // We just reconfigure the JLabel each time we're called.

    public Component getListCellRendererComponent(
      JList<?> list,           // the list
      Object value,            // value to display
      int index,               // cell index
      boolean isSelected,      // is the cell selected
      boolean cellHasFocus)    // does the cell have focus
    {
        String s = value.toString();
        setText(s);
        setIcon((s.length() > 10) ? longIcon : shortIcon);
        if (isSelected) {
            setBackground(list.getSelectionBackground());
            setForeground(list.getSelectionForeground());
        } else {
            setBackground(list.getBackground());
            setForeground(list.getForeground());
        }
        setEnabled(list.isEnabled());
        setFont(list.getFont());
        setOpaque(true);
        return this;
    }
}

myList.setCellRenderer(new MyCellRenderer());

Another job for the cell renderer is in helping to determine sizing
information for the list. By default, the list's ListUI determines
the size of cells by asking the cell renderer for its preferred
size for each list item. This can be expensive for large lists of items.
To avoid these calculations, you can set a fixedCellWidth and
fixedCellHeight on the list, or have these values calculated
automatically based on a single prototype value:



JList<String> bigDataList = new JList<String>(bigData);

// We don't want the JList implementation to compute the width
// or height of all of the list cells, so we give it a string
// that's as big as we'll need for any cell.  It uses this to
// compute values for the fixedCellWidth and fixedCellHeight
// properties.

bigDataList.setPrototypeCellValue("Index 1234567890");

JList doesn't implement scrolling directly. To create a list that
scrolls, make it the viewport view of a JScrollPane. For example:


JScrollPane scrollPane = new JScrollPane(myList);

// Or in two steps:
JScrollPane scrollPane = new JScrollPane();
scrollPane.getViewport().setView(myList);

JList doesn't provide any special handling of double or triple
(or N) mouse clicks, but it's easy to add a MouseListener if you
wish to take action on these events. Use the locationToIndex
method to determine what cell was clicked. For example:


MouseListener mouseListener = new MouseAdapter() {
    public void mouseClicked(MouseEvent e) {
        if (e.getClickCount() == 2) {
            int index = list.locationToIndex(e.getPoint());
            System.out.println("Double clicked on Item "  index);
         }
    }
};
list.addMouseListener(mouseListener);

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

See How to Use Lists
in The Java Tutorial
for further documentation.

A subclass of TransferHandler.DropLocation representing
a drop location for a JList.

An implementation of a menu -- a popup window containing
JMenuItems that
is displayed when the user selects an item on the JMenuBar.
In addition to JMenuItems, a JMenu can
also contain JSeparators.

In essence, a menu is a button with an associated JPopupMenu.
When the "button" is pressed, the JPopupMenu appears. If the
"button" is on the JMenuBar, the menu is a top-level window.
If the "button" is another menu item, then the JPopupMenu is
"pull-right" menu.

Menus can be configured, and to some degree controlled, by
Actions.  Using an
Action with a menu has many benefits beyond directly
configuring a menu.  Refer to
Swing Components Supporting Action for more
details, and you can find more information in How
to Use Actions, a section in The Java Tutorial.

For information and examples of using menus see
How to Use Menus,
a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

An implementation of a menu bar. You add JMenu objects to the
menu bar to construct a menu. When the user selects a JMenu
object, its associated JPopupMenu is displayed, allowing the
user to select one of the JMenuItems on it.

For information and examples of using menu bars see
How to Use Menus,
a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

Warning:
By default, pressing the Tab key does not transfer focus from a
JMenuBar which is added to a container together with other Swing
components, because the focusTraversalKeysEnabled property
of JMenuBar is set to false. To resolve this,
you should call the JMenuBar.setFocusTraversalKeysEnabled(true)
method.

An implementation of an item in a menu. A menu item is essentially a button
sitting in a list. When the user selects the "button", the action
associated with the menu item is performed. A JMenuItem
contained in a JPopupMenu performs exactly that function.

Menu items can be configured, and to some degree controlled, by
Actions.  Using an
Action with a menu item has many benefits beyond directly
configuring a menu item.  Refer to
Swing Components Supporting Action for more
details, and you can find more information in How
to Use Actions, a section in The Java Tutorial.

For further documentation and for examples, see
How to Use Menus
in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

Method Name
Description


showConfirmDialog
Asks a confirming question, like yes/no/cancel.


showInputDialog
Prompt for some input.

 JOptionPane pane = new JOptionPane(arguments);
 pane.set.Xxxx(...); // Configure
 JDialog dialog = pane.createDialog(parentComponent, title);
 dialog.show();
 Object selectedValue = pane.getValue();
 if(selectedValue == null)
   return CLOSED_OPTION;
 //If there is not an array of option buttons:
 if(options == null) {
   if(selectedValue instanceof Integer)
      return ((Integer)selectedValue).intValue();
   return CLOSED_OPTION;
 }
 //If there is an array of option buttons:
 for(int counter = 0, maxCounter = options.length;
    counter < maxCounter; counter++) {
    if(options[counter].equals(selectedValue))
    return counter;
 }
 return CLOSED_OPTION;

JOptionPane makes it easy to pop up a standard dialog box that
 prompts users for a value or informs them of something.
 For information about using JOptionPane, see
 How to Make Dialogs,
 a section in The Java Tutorial.



 While the JOptionPane
 class may appear complex because of the large number of methods, almost
 all uses of this class are one-line calls to one of the static
 showXxxDialog methods shown below:





    Method Name
    Description


    showConfirmDialog
    Asks a confirming question, like yes/no/cancel.


    showInputDialog
    Prompt for some input.


   showMessageDialog
   Tell the user about something that has happened.


   showOptionDialog
   The Grand Unification of the above three.




 Each of these methods also comes in a showInternalXXX
 flavor, which uses an internal frame to hold the dialog box (see
 JInternalFrame).
 Multiple convenience methods have also been defined -- overloaded
 versions of the basic methods that use different parameter lists.

 All dialogs are modal. Each showXxxDialog method blocks
 the caller until the user's interaction is complete.



  icon
  message


  input value


   option buttons



 The basic appearance of one of these dialog boxes is generally
 similar to the picture at the right, although the various
 look-and-feels are
 ultimately responsible for the final result.  In particular, the
 look-and-feels will adjust the layout to accommodate the option pane's
 ComponentOrientation property.


 Parameters:
 The parameters to these methods follow consistent patterns:


 parentComponent
 Defines the Component that is to be the parent of this
 dialog box.
 It is used in two ways: the Frame that contains
 it is used as the Frame
 parent for the dialog box, and its screen coordinates are used in
 the placement of the dialog box. In general, the dialog box is placed
 just below the component. This parameter may be null,
 in which case a default Frame is used as the parent,
 and the dialog will be
 centered on the screen (depending on the L&F).
 message
 A descriptive message to be placed in the dialog box.
 In the most common usage, message is just a String or
 String constant.
 However, the type of this parameter is actually Object. Its
 interpretation depends on its type:

 Object[]An array of objects is interpreted as a series of
                 messages (one per object) arranged in a vertical stack.
                 The interpretation is recursive -- each object in the
                 array is interpreted according to its type.
 ComponentThe Component is displayed in the dialog.
 IconThe Icon is wrapped in a JLabel
               and displayed in the dialog.
 othersThe object is converted to a String by calling
               its toString method. The result is wrapped in a
               JLabel and displayed.

 messageTypeDefines the style of the message. The Look and Feel
 manager may lay out the dialog differently depending on this value, and
 will often provide a default icon. The possible values are:

 ERROR_MESSAGE
 INFORMATION_MESSAGE
 WARNING_MESSAGE
 QUESTION_MESSAGE
 PLAIN_MESSAGE

 optionTypeDefines the set of option buttons that appear at
 the bottom of the dialog box:

 DEFAULT_OPTION
 YES_NO_OPTION
 YES_NO_CANCEL_OPTION
 OK_CANCEL_OPTION

 You aren't limited to this set of option buttons.  You can provide any
 buttons you want using the options parameter.
 optionsA more detailed description of the set of option buttons
 that will appear at the bottom of the dialog box.
 The usual value for the options parameter is an array of
 Strings. But
 the parameter type is an array of Objects.
 A button is created for each object depending on its type:

 ComponentThe component is added to the button row directly.
 IconA JButton is created with this as its label.
 otherThe Object is converted to a string using its
              toString method and the result is used to
              label a JButton.

 iconA decorative icon to be placed in the dialog box. A default
 value for this is determined by the messageType parameter.
 titleThe title for the dialog box.
 initialValueThe default selection (input value).



 When the selection is changed, setValue is invoked,
 which generates a PropertyChangeEvent.

 If a JOptionPane has configured to all input
 setWantsInput
 the bound property JOptionPane.INPUT_VALUE_PROPERTY
  can also be listened
 to, to determine when the user has input or selected a value.

 When one of the showXxxDialog methods returns an integer,
 the possible values are:

 YES_OPTION
 NO_OPTION
 CANCEL_OPTION
 OK_OPTION
 CLOSED_OPTION

 Examples:

 Show an error dialog that displays the message, 'alert':

 JOptionPane.showMessageDialog(null, "alert", "alert", JOptionPane.ERROR_MESSAGE);

 Show an internal information dialog with the message, 'information':


 JOptionPane.showInternalMessageDialog(frame, "information",
             "information", JOptionPane.INFORMATION_MESSAGE);
 Show an information panel with the options yes/no and message 'choose one':


JOptionPane.showConfirmDialog(null,
             "choose one", "choose one", JOptionPane.YES_NO_OPTION);
 Show an internal information dialog with the options yes/no/cancel and
 message 'please choose one' and title information:


JOptionPane.showInternalConfirmDialog(frame,
             "please choose one", "information",
             JOptionPane.YES_NO_CANCEL_OPTION, JOptionPane.INFORMATION_MESSAGE);
 Show a warning dialog with the options OK, CANCEL, title 'Warning', and
 message 'Click OK to continue':


 Object[] options = { "OK", "CANCEL" };
 JOptionPane.showOptionDialog(null, "Click OK to continue", "Warning",
             JOptionPane.DEFAULT_OPTION, JOptionPane.WARNING_MESSAGE,
             null, options, options[0]);
 Show a dialog asking the user to type in a String:

 String inputValue = JOptionPane.showInputDialog("Please input a value");

 Show a dialog asking the user to select a String:


 Object[] possibleValues = { "First", "Second", "Third" };
 Object selectedValue = JOptionPane.showInputDialog(null,
             "Choose one", "Input",
             JOptionPane.INFORMATION_MESSAGE, null,
             possibleValues, possibleValues[0]);

 Direct Use:
 To create and use an JOptionPane directly, the
 standard pattern is roughly as follows:


     JOptionPane pane = new JOptionPane(arguments);
     pane.set.Xxxx(...); // Configure
     JDialog dialog = pane.createDialog(parentComponent, title);
     dialog.show();
     Object selectedValue = pane.getValue();
     if(selectedValue == null)
       return CLOSED_OPTION;
     //If there is not an array of option buttons:
     if(options == null) {
       if(selectedValue instanceof Integer)
          return ((Integer)selectedValue).intValue();
       return CLOSED_OPTION;
     }
     //If there is an array of option buttons:
     for(int counter = 0, maxCounter = options.length;
        counter < maxCounter; counter++) {
        if(options[counter].equals(selectedValue))
        return counter;
     }
     return CLOSED_OPTION;

 Warning: Swing is not thread safe. For more
 information see Swing's Threading
 Policy.

 Warning:
 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 java.beans package.
 Please see XMLEncoder.

JPanel is a generic lightweight container.
For examples and task-oriented documentation for JPanel, see
How to Use Panels,
a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

JPasswordField is a lightweight component that allows
the editing of a single line of text where the view indicates
something was typed, but does not show the original characters.
You can find further information and examples in
How to Use Text Fields,
a section in The Java Tutorial.

JPasswordField is intended
to be source-compatible with java.awt.TextField
used with echoChar set.  It is provided separately
to make it easier to safely change the UI for the
JTextField without affecting password entries.

NOTE:
By default, JPasswordField disables input methods; otherwise, input
characters could be visible while they were composed using input methods.
If an application needs the input methods support, please use the
inherited method, enableInputMethods(true).

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

An implementation of a popup menu -- a small window that pops up
and displays a series of choices. A JPopupMenu is used for the
menu that appears when the user selects an item on the menu bar.
It is also used for "pull-right" menu that appears when the
selects a menu item that activates it. Finally, a JPopupMenu
can also be used anywhere else you want a menu to appear.  For
example, when the user right-clicks in a specified area.

For information and examples of using popup menus, see
How to Use Menus
in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A popup menu-specific separator.

A component that visually displays the progress of some task.  As the task
 progresses towards completion, the progress bar displays the
 task's percentage of completion.
 This percentage is typically represented visually by a rectangle which
 starts out empty and gradually becomes filled in as the task progresses.
 In addition, the progress bar can display a textual representation of this
 percentage.

 JProgressBar uses a BoundedRangeModel as its data model,
 with the value property representing the "current" state of the task,
 and the minimum and maximum properties representing the
 beginning and end points, respectively.

 To indicate that a task of unknown length is executing,
 you can put a progress bar into indeterminate mode.
 While the bar is in indeterminate mode,
 it animates constantly to show that work is occurring.
 As soon as you can determine the task's length and amount of progress,
 you should update the progress bar's value
 and switch it back to determinate mode.



 Here is an example of creating a progress bar,
 where task is an object (representing some piece of work)
 which returns information about the progress of the task:



progressBar = new JProgressBar(0, task.getLengthOfTask());
progressBar.setValue(0);
progressBar.setStringPainted(true);

 Here is an example of querying the current state of the task, and using
 the returned value to update the progress bar:



progressBar.setValue(task.getCurrent());

 Here is an example of putting a progress bar into
 indeterminate mode,
 and then switching back to determinate mode
 once the length of the task is known:



progressBar = new JProgressBar();
...//when the task of (initially) unknown length begins:
progressBar.setIndeterminate(true);
...//do some work; get length of task...
progressBar.setMaximum(newLength);
progressBar.setValue(newValue);
progressBar.setIndeterminate(false);



 For complete examples and further documentation see
 How to Monitor Progress,
 a section in The Java Tutorial.


 Warning: Swing is not thread safe. For more
 information see Swing's Threading
 Policy.

 Warning:
 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 java.beans package.
 Please see XMLEncoder.

An implementation of a radio button -- an item that can be selected or
deselected, and which displays its state to the user.
Used with a ButtonGroup object to create a group of buttons
in which only one button at a time can be selected. (Create a ButtonGroup
object and use its add method to include the JRadioButton objects
in the group.)

Note:
The ButtonGroup object is a logical grouping -- not a physical grouping.
To create a button panel, you should still create a JPanel or similar
container-object and add a Border to it to set it off from surrounding
components.


Buttons can be configured, and to some degree controlled, by
Actions.  Using an
Action with a button has many benefits beyond directly
configuring a button.  Refer to
Swing Components Supporting Action for more
details, and you can find more information in How
to Use Actions, a section in The Java Tutorial.

See How to Use Buttons, Check Boxes, and Radio Buttons
in The Java Tutorial
for further documentation.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

An implementation of a radio button menu item.
A JRadioButtonMenuItem is
a menu item that is part of a group of menu items in which only one
item in the group can be selected. The selected item displays its
selected state. Selecting it causes any other selected item to
switch to the unselected state.
To control the selected state of a group of radio button menu items,
use a ButtonGroup object.

Menu items can be configured, and to some degree controlled, by
Actions.  Using an
Action with a menu item has many benefits beyond directly
configuring a menu item.  Refer to
Swing Components Supporting Action for more
details, and you can find more information in How
to Use Actions, a section in The Java Tutorial.

For further documentation and examples see
How to Use Menus,
a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

  rootPane.getContentPane().add(child);

A lightweight container used behind the scenes by
JFrame, JDialog, JWindow,
JApplet, and JInternalFrame.
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 (JFrame, JDialog,
JWindow, and 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
JInternalFrame is also shown.
All five of these JFC/Swing containers implement the
RootPaneContainer interface,
and they all delegate their operations to a
JRootPane (shown with a little "handle" on top).

Note: The JComponent method getRootPane
can be used to obtain the JRootPane that contains
a given component.








The diagram at right shows the structure of a JRootPane.
A JRootpane is made up of a glassPane,
an optional menuBar, and a contentPane.
(The JLayeredPane manages the menuBar
and the contentPane.)
The glassPane sits over the top of everything,
where it is in a position to intercept mouse movements.
Since the glassPane (like the contentPane)
can be an arbitrary component, it is also possible to set up the
glassPane for drawing. Lines and images on the
glassPane can then range
over the frames underneath without being limited by their boundaries.

Although the menuBar component is optional,
the layeredPane, contentPane,
and 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 contentPane
of 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 contentPane instead of on the JRootPane.

Note: The default layout manager for the contentPane is
 a BorderLayout manager. However, the JRootPane
 uses 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());
If a JMenuBar component is set on the JRootPane,
it is positioned along the upper edge of the frame.
The contentPane is adjusted in location and size to
fill the remaining area.
(The JMenuBar and the contentPane are added to the
layeredPane component at the
JLayeredPane.FRAME_CONTENT_LAYER layer.)

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 contentPane.
It is an instance of JLayeredPane,
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.

The glassPane sits on top of all other components in the
JRootPane.
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 glassPane
to control when the glassPane displays over the other children.
By default the glassPane is not visible.

The custom LayoutManager used by JRootPane
ensures that:

The glassPane fills the entire viewable
    area of the JRootPane (bounds - insets).
The layeredPane fills the entire viewable area of the
    JRootPane. (bounds - insets)
The menuBar is positioned at the upper edge of the
    layeredPane.
The contentPane fills the entire viewable area,
    minus the menuBar, if present.

Any other views in the JRootPane view hierarchy are ignored.

If you replace the LayoutManager of the JRootPane,
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
for the JRootPane itself!

The painting architecture of Swing requires an opaque
JComponent
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
overrides paintComponent, it
will need to completely fill in the background in an opaque color in
paintComponent.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

An implementation of a scrollbar. The user positions the knob in the
scrollbar to determine the contents of the viewing area. The
program typically adjusts the display so that the end of the
scrollbar represents the end of the displayable contents, or 100%
of the contents. The start of the scrollbar is the beginning of the
displayable contents, or 0%. The position of the knob within
those bounds then translates to the corresponding percentage of
the displayable contents.

Typically, as the position of the knob in the scrollbar changes
a corresponding change is made to the position of the JViewport on
the underlying view, changing the contents of the JViewport.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

Provides a scrollable view of a lightweight component.
A JScrollPane manages a viewport, optional
vertical and horizontal scroll bars, and optional row and
column heading viewports.
You can find task-oriented documentation of JScrollPane in
 How to Use Scroll Panes,
a section in The Java Tutorial.  Note that
JScrollPane does not support heavyweight components.








The JViewport provides a window,
or "viewport" onto a data
source -- for example, a text file. That data source is the
"scrollable client" (aka data model) displayed by the
JViewport view.
A JScrollPane basically consists of JScrollBars,
a JViewport, and the wiring between them,
as shown in the diagram at right.

In addition to the scroll bars and viewport,
a JScrollPane can have a
column header and a row header. Each of these is a
JViewport object that
you specify with setRowHeaderView,
and setColumnHeaderView.
The column header viewport automatically scrolls left and right, tracking
the left-right scrolling of the main viewport.
(It never scrolls vertically, however.)
The row header acts in a similar fashion.

Where two scroll bars meet, the row header meets the column header,
or a scroll bar meets one of the headers, both components stop short
of the corner, leaving a rectangular space which is, by default, empty.
These spaces can potentially exist in any number of the four corners.
In the previous diagram, the top right space is present and identified
by the label "corner component".

Any number of these empty spaces can be replaced by using the
setCorner method to add a component to a particular corner.
(Note: The same component cannot be added to multiple corners.)
This is useful if there's
some extra decoration or function you'd like to add to the scroll pane.
The size of each corner component is entirely determined by the size of the
headers and/or scroll bars that surround it.

A corner component will only be visible if there is an empty space in that
corner for it to exist in. For example, consider a component set into the
top right corner of a scroll pane with a column header. If the scroll pane's
vertical scrollbar is not present, perhaps because the view component hasn't
grown large enough to require it, then the corner component will not be
shown (since there is no empty space in that corner created by the meeting
of the header and vertical scroll bar). Forcing the scroll bar to always be
shown, using
setVerticalScrollBarPolicy(VERTICAL_SCROLLBAR_ALWAYS),
will ensure that the space for the corner component always exists.

To add a border around the main viewport,
you can use setViewportBorder.
(Of course, you can also add a border around the whole scroll pane using
setBorder.)

A common operation to want to do is to set the background color that will
be used if the main viewport view is smaller than the viewport, or is
not opaque. This can be accomplished by setting the background color
of the viewport, via scrollPane.getViewport().setBackground().
The reason for setting the color of the viewport and not the scrollpane
is that by default JViewport is opaque
which, among other things, means it will completely fill
in its background using its background color.  Therefore when
JScrollPane draws its background the viewport will
usually draw over it.

By default JScrollPane uses ScrollPaneLayout
to handle the layout of its child Components. ScrollPaneLayout
determines the size to make the viewport view in one of two ways:

  If the view implements Scrollable
      a combination of getPreferredScrollableViewportSize,
      getScrollableTracksViewportWidth and
      getScrollableTracksViewportHeightis used, otherwise
  getPreferredSize is used.


Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

JSeparator provides a general purpose component for
implementing divider lines - most commonly used as a divider
between menu items that breaks them up into logical groupings.
Instead of using JSeparator directly,
you can use the JMenu or JPopupMenu
addSeparator method to create and add a separator.
JSeparators may also be used elsewhere in a GUI
wherever a visual divider is useful.



For more information and examples see
How to Use Menus,
a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A component that lets the user graphically select a value by sliding
a knob within a bounded interval. The knob is always positioned
at the points that match integer values within the specified interval.

The slider can show both
major tick marks, and minor tick marks between the major ones.  The number of
values between the tick marks is controlled with
setMajorTickSpacing and setMinorTickSpacing.
Painting of tick marks is controlled by setPaintTicks.

Sliders can also print text labels at regular intervals (or at
arbitrary locations) along the slider track.  Painting of labels is
controlled by setLabelTable and setPaintLabels.

For further information and examples see
How to Use Sliders,
a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A single line input field that lets the user select a
number or an object value from an ordered sequence. Spinners typically
provide a pair of tiny arrow buttons for stepping through the elements
of the sequence. The keyboard up/down arrow keys also cycle through the
elements. The user may also be allowed to type a (legal) value directly
into the spinner. Although combo boxes provide similar functionality,
spinners are sometimes preferred because they don't require a drop down list
that can obscure important data.

A JSpinner's sequence value is defined by its
SpinnerModel.
The model can be specified as a constructor argument and
changed with the model property.  SpinnerModel
classes for some common types are provided: SpinnerListModel,
SpinnerNumberModel, and SpinnerDateModel.

A JSpinner has a single child component that's
responsible for displaying
and potentially changing the current element or value of
the model, which is called the editor.  The editor is created
by the JSpinner's constructor and can be changed with the
editor property.  The JSpinner's editor stays
in sync with the model by listening for ChangeEvents. If the
user has changed the value displayed by the editor it is
possible for the model's value to differ from that of
the editor. To make sure the model has the same
value as the editor use the commitEdit method, eg:


  try {
      spinner.commitEdit();
  }
  catch (ParseException pe) {
      // Edited value is invalid, spinner.getValue() will return
      // the last valid value, you could revert the spinner to show that:
      JComponent editor = spinner.getEditor();
      if (editor instanceof DefaultEditor) {
          ((DefaultEditor)editor).getTextField().setValue(spinner.getValue());
      }
      // reset the value to some known value:
      spinner.setValue(fallbackValue);
      // or treat the last valid value as the current, in which
      // case you don't need to do anything.
  }
  return spinner.getValue();

For information and examples of using spinner see
How to Use Spinners,
a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

An editor for a JSpinner whose model is a
SpinnerDateModel.  The value of the editor is
displayed with a JFormattedTextField whose format
is defined by a DateFormatter instance whose
minimum and maximum properties
are mapped to the SpinnerDateModel.

A simple base class for more specialized editors
that displays a read-only view of the model's current
value with a JFormattedTextField.  Subclasses
can configure the JFormattedTextField to create
an editor that's appropriate for the type of model they
support and they may want to override
the stateChanged and propertyChanged
methods, which keep the model and the text field in sync.

This class defines a dismiss method that removes the
editors ChangeListener from the JSpinner
that it's part of.   The setEditor method knows about
DefaultEditor.dismiss, so if the developer
replaces an editor that's derived from JSpinner.DefaultEditor
its ChangeListener connection back to the
JSpinner will be removed.  However after that,
it's up to the developer to manage their editor listeners.
Similarly, if a subclass overrides createEditor,
it's up to the subclasser to deal with their editor
subsequently being replaced (with setEditor).
We expect that in most cases, and in editor installed
with setEditor or created by a createEditor
override, will not be replaced anyway.

This class is the LayoutManager for it's single
JFormattedTextField child.   By default the
child is just centered with the parents insets.

An editor for a JSpinner whose model is a
SpinnerListModel.

An editor for a JSpinner whose model is a
SpinnerNumberModel.  The value of the editor is
displayed with a JFormattedTextField whose format
is defined by a NumberFormatter instance whose
minimum and maximum properties
are mapped to the SpinnerNumberModel.

JSplitPane is used to divide two (and only two)
Components. The two Components
are graphically divided based on the look and feel
implementation, and the two Components can then be
interactively resized by the user.
Information on using JSplitPane is in
How to Use Split Panes in
The Java Tutorial.

The two Components in a split pane can be aligned
left to right using
JSplitPane.HORIZONTAL_SPLIT, or top to bottom using
JSplitPane.VERTICAL_SPLIT.
The preferred way to change the size of the Components
is to invoke
setDividerLocation where location is either
the new x or y position, depending on the orientation of the
JSplitPane.

To resize the Components to their preferred sizes invoke
resetToPreferredSizes.

When the user is resizing the Components the minimum
size of the Components is used to determine the
maximum/minimum position the Components
can be set to. If the minimum size of the two
components is greater than the size of the split pane the divider
will not allow you to resize it. To alter the minimum size of a
JComponent, see JComponent.setMinimumSize(java.awt.Dimension).

When the user resizes the split pane the new space is distributed between
the two components based on the resizeWeight property.
A value of 0,
the default, indicates the right/bottom component gets all the space,
where as a value of 1 indicates the left/top component gets all the space.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A component that lets the user switch between a group of components by
clicking on a tab with a given title and/or icon.
For examples and information on using tabbed panes see
How to Use Tabbed Panes,
a section in The Java Tutorial.

Tabs/components are added to a TabbedPane object by using the
addTab and insertTab methods.
A tab is represented by an index corresponding
to the position it was added in, where the first tab has an index equal to 0
and the last tab has an index equal to the tab count minus 1.

The TabbedPane uses a SingleSelectionModel
to represent the set
of tab indices and the currently selected index.  If the tab count
is greater than 0, then there will always be a selected index, which
by default will be initialized to the first tab.  If the tab count is
0, then the selected index will be -1.

The tab title can be rendered by a Component.
For example, the following produce similar results:


// In this case the look and feel renders the title for the tab.
tabbedPane.addTab("Tab", myComponent);
// In this case the custom component is responsible for rendering the
// title of the tab.
tabbedPane.addTab(null, myComponent);
tabbedPane.setTabComponentAt(0, new JLabel("Tab"));
The latter is typically used when you want a more complex user interaction
that requires custom components on the tab.  For example, you could
provide a custom component that animates or one that has widgets for
closing the tab.

If you specify a component for a tab, the JTabbedPane
will not render any text or icon you have specified for the tab.

Note:
Do not use setVisible directly on a tab component to make it visible,
use setSelectedComponent or setSelectedIndex methods instead.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

 TableModel dataModel = new AbstractTableModel() {
     public int getColumnCount() { return 10; }
     public int getRowCount() { return 10;}
     public Object getValueAt(int row, int col) { return new Integer(row*col); }
 };
 JTable table = new JTable(dataModel);
 JScrollPane scrollpane = new JScrollPane(table);

The JTable is used to display and edit regular two-dimensional tables
of cells.
See How to Use Tables
in The Java Tutorial
for task-oriented documentation and examples of using JTable.


The JTable has many
facilities that make it possible to customize its rendering and editing
but provides defaults for these features so that simple tables can be
set up easily.  For example, to set up a table with 10 rows and 10
columns of numbers:



     TableModel dataModel = new AbstractTableModel() {
         public int getColumnCount() { return 10; }
         public int getRowCount() { return 10;}
         public Object getValueAt(int row, int col) { return new Integer(row*col); }
     };
     JTable table = new JTable(dataModel);
     JScrollPane scrollpane = new JScrollPane(table);

JTables are typically placed inside of a JScrollPane.  By
default, a JTable will adjust its width such that
a horizontal scrollbar is unnecessary.  To allow for a horizontal scrollbar,
invoke setAutoResizeMode(int) with AUTO_RESIZE_OFF.
Note that if you wish to use a JTable in a standalone
view (outside of a JScrollPane) and want the header
displayed, you can get it using getTableHeader() and
display it separately.

To enable sorting and filtering of rows, use a
RowSorter.
You can set up a row sorter in either of two ways:

  Directly set the RowSorter. For example:
       table.setRowSorter(new TableRowSorter(model)).
  Set the autoCreateRowSorter
      property to true, so that the JTable
      creates a RowSorter for
      you. For example: setAutoCreateRowSorter(true).


When designing applications that use the JTable it is worth paying
close attention to the data structures that will represent the table's data.
The DefaultTableModel is a model implementation that
uses a Vector of Vectors of Objects to
store the cell values. As well as copying the data from an
application into the DefaultTableModel,
it is also possible to wrap the data in the methods of the
TableModel interface so that the data can be passed to the
JTable directly, as in the example above. This often results
in more efficient applications because the model is free to choose the
internal representation that best suits the data.
A good rule of thumb for deciding whether to use the AbstractTableModel
or the DefaultTableModel is to use the AbstractTableModel
as the base class for creating subclasses and the DefaultTableModel
when subclassing is not required.

The "TableExample" directory in the demo area of the source distribution
gives a number of complete examples of JTable usage,
covering how the JTable can be used to provide an
editable view of data taken from a database and how to modify
the columns in the display to use specialized renderers and editors.

The JTable uses integers exclusively to refer to both the rows and the columns
of the model that it displays. The JTable simply takes a tabular range of cells
and uses getValueAt(int, int) to retrieve the
values from the model during painting.  It is important to remember that
the column and row indexes returned by various JTable methods
are in terms of the JTable (the view) and are not
necessarily the same indexes used by the model.

By default, columns may be rearranged in the JTable so that the
view's columns appear in a different order to the columns in the model.
This does not affect the implementation of the model at all: when the
columns are reordered, the JTable maintains the new order of the columns
internally and converts its column indices before querying the model.

So, when writing a TableModel, it is not necessary to listen for column
reordering events as the model will be queried in its own coordinate
system regardless of what is happening in the view.
In the examples area there is a demonstration of a sorting algorithm making
use of exactly this technique to interpose yet another coordinate system
where the order of the rows is changed, rather than the order of the columns.

Similarly when using the sorting and filtering functionality
provided by RowSorter the underlying
TableModel does not need to know how to do sorting,
rather RowSorter will handle it.  Coordinate
conversions will be necessary when using the row based methods of
JTable with the underlying TableModel.
All of JTables row based methods are in terms of the
RowSorter, which is not necessarily the same as that
of the underlying TableModel.  For example, the
selection is always in terms of JTable so that when
using RowSorter you will need to convert using
convertRowIndexToView or
convertRowIndexToModel.  The following shows how to
convert coordinates from JTable to that of the
underlying model:


  int[] selection = table.getSelectedRows();
  for (int i = 0; i < selection.length; i++) {
    selection[i] = table.convertRowIndexToModel(selection[i]);
  }
  // selection is now in terms of the underlying TableModel

By default if sorting is enabled JTable will persist the
selection and variable row heights in terms of the model on
sorting.  For example if row 0, in terms of the underlying model,
is currently selected, after the sort row 0, in terms of the
underlying model will be selected.  Visually the selection may
change, but in terms of the underlying model it will remain the
same.  The one exception to that is if the model index is no longer
visible or was removed.  For example, if row 0 in terms of model
was filtered out the selection will be empty after the sort.

J2SE 5 adds methods to JTable to provide convenient access to some
common printing needs. Simple new print() methods allow for quick
and easy addition of printing support to your application. In addition, a new
getPrintable(javax.swing.JTable.PrintMode, java.text.MessageFormat, java.text.MessageFormat) method is available for more advanced printing needs.

As for all JComponent classes, you can use
InputMap and ActionMap to associate an
Action object with a KeyStroke and execute the
action under specified conditions.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A subclass of TransferHandler.DropLocation representing
a drop location for a JTable.

A JTextArea is a multi-line area that displays plain text.
It is intended to be a lightweight component that provides source
compatibility with the java.awt.TextArea class where it can
reasonably do so.
You can find information and examples of using all the text components in
Using Text Components,
a section in The Java Tutorial.


This component has capabilities not found in the
java.awt.TextArea class.  The superclass should be
consulted for additional capabilities.
Alternative multi-line text classes with
more capabilities are JTextPane and JEditorPane.

The java.awt.TextArea internally handles scrolling.
JTextArea is different in that it doesn't manage scrolling,
but implements the swing Scrollable interface.  This allows it
to be placed inside a JScrollPane if scrolling
behavior is desired, and used directly if scrolling is not desired.

The java.awt.TextArea has the ability to do line wrapping.
This was controlled by the horizontal scrolling policy.  Since
scrolling is not done by JTextArea directly, backward
compatibility must be provided another way.  JTextArea has
a bound property for line wrapping that controls whether or
not it will wrap lines.  By default, the line wrapping property
is set to false (not wrapped).

java.awt.TextArea has two properties rows
and columns that are used to determine the preferred size.
JTextArea uses these properties to indicate the
preferred size of the viewport when placed inside a JScrollPane
to match the functionality provided by java.awt.TextArea.
JTextArea has a preferred size of what is needed to
display all of the text, so that it functions properly inside of
a JScrollPane.  If the value for rows
or columns is equal to zero,
the preferred size along that axis is used for
the viewport preferred size along the same axis.

The java.awt.TextArea could be monitored for changes by adding
a TextListener for TextEvents.
In the JTextComponent based
components, changes are broadcasted from the model via a
DocumentEvent to DocumentListeners.
The DocumentEvent gives
the location of the change and the kind of change if desired.
The code fragment might look something like:


   DocumentListener myListener = ??;
   JTextArea myArea = ??;
   myArea.getDocument().addDocumentListener(myListener);


Newlines

For a discussion on how newlines are handled, see
DefaultEditorKit.



Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

DocumentListener myListener = ??;
JTextField myArea = ??;
myArea.getDocument().addDocumentListener(myListener);

public UpperCaseField(int cols) {
    super(cols);
}

protected Document createDefaultModel() {
    return new UpperCaseDocument();
}

static class UpperCaseDocument extends PlainDocument {

    public void insertString(int offs, String str, AttributeSet a)
        throws BadLocationException {

        if (str == null) {
            return;
        }
        char[] upper = str.toCharArray();
        for (int i = 0; i < upper.length; i++) {
            upper[i] = Character.toUpperCase(upper[i]);
        }
        super.insertString(offs, new String(upper), a);
    }
}

JTextField is a lightweight component that allows the editing
of a single line of text.
For information on and examples of using text fields,
see
How to Use Text Fields
in The Java Tutorial.


JTextField is intended to be source-compatible
with java.awt.TextField where it is reasonable to do so.  This
component has capabilities not found in the java.awt.TextField
class.  The superclass should be consulted for additional capabilities.

JTextField has a method to establish the string used as the
command string for the action event that gets fired.  The
java.awt.TextField used the text of the field as the command
string for the ActionEvent.
JTextField will use the command
string set with the setActionCommand method if not null,
otherwise it will use the text of the field as a compatibility with
java.awt.TextField.

The method setEchoChar and getEchoChar
are not provided directly to avoid a new implementation of a
pluggable look-and-feel inadvertently exposing password characters.
To provide password-like services a separate class JPasswordField
extends JTextField to provide this service with an independently
pluggable look-and-feel.

The java.awt.TextField could be monitored for changes by adding
a TextListener for TextEvent's.
In the JTextComponent based
components, changes are broadcasted from the model via a
DocumentEvent to DocumentListeners.
The DocumentEvent gives
the location of the change and the kind of change if desired.
The code fragment might look something like:


    DocumentListener myListener = ??;
    JTextField myArea = ??;
    myArea.getDocument().addDocumentListener(myListener);

The horizontal alignment of JTextField can be set to be left
justified, leading justified, centered, right justified or trailing justified.
Right/trailing justification is useful if the required size
of the field text is smaller than the size allocated to it.
This is determined by the setHorizontalAlignment
and getHorizontalAlignment methods.  The default
is to be leading justified.

How the text field consumes VK_ENTER events depends
on whether the text field has any action listeners.
If so, then VK_ENTER results in the listeners
getting an ActionEvent,
and the VK_ENTER event is consumed.
This is compatible with how AWT text fields handle VK_ENTER events.
If the text field has no action listeners, then as of v 1.3 the VK_ENTER
event is not consumed.  Instead, the bindings of ancestor components
are processed, which enables the default button feature of
JFC/Swing to work.

Customized fields can easily be created by extending the model and
changing the default model provided.  For example, the following piece
of code will create a field that holds only upper case characters.  It
will work even if text is pasted into from the clipboard or it is altered via
programmatic changes.


public class UpperCaseField extends JTextField {

    public UpperCaseField(int cols) {
        super(cols);
    }

    protected Document createDefaultModel() {
        return new UpperCaseDocument();
    }

    static class UpperCaseDocument extends PlainDocument {

        public void insertString(int offs, String str, AttributeSet a)
            throws BadLocationException {

            if (str == null) {
                return;
            }
            char[] upper = str.toCharArray();
            for (int i = 0; i < upper.length; i++) {
                upper[i] = Character.toUpperCase(upper[i]);
            }
            super.insertString(offs, new String(upper), a);
        }
    }
}

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A text component that can be marked up with attributes that are
represented graphically.
You can find how-to information and examples of using text panes in
Using Text Components,
a section in The Java Tutorial.


This component models paragraphs
that are composed of runs of character level attributes.  Each
paragraph may have a logical style attached to it which contains
the default attributes to use if not overridden by attributes set
on the paragraph or character run.  Components and images may
be embedded in the flow of text.


Newlines

For a discussion on how newlines are handled, see
DefaultEditorKit.



Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

An implementation of a two-state button.
The JRadioButton and JCheckBox classes
are subclasses of this class.
For information on using them see
How to Use Buttons, Check Boxes, and Radio Buttons,
a section in The Java Tutorial.

Buttons can be configured, and to some degree controlled, by
Actions.  Using an
Action with a button has many benefits beyond directly
configuring a button.  Refer to
Swing Components Supporting Action for more
details, and you can find more information in How
to Use Actions, a section in The Java Tutorial.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

The ToggleButton model

Warning:
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 java.beans package.
Please see XMLEncoder.

JToolBar provides a component that is useful for
displaying commonly used Actions or controls.
For examples and information on using tool bars see
How to Use Tool Bars,
a section in The Java Tutorial.


With most look and feels,
the user can drag out a tool bar into a separate window
(unless the floatable property is set to false).
For drag-out to work correctly, it is recommended that you add
JToolBar instances to one of the four "sides" of a
container whose layout manager is a BorderLayout,
and do not add children to any of the other four "sides".

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A toolbar-specific separator. An object with dimension but
no contents used to divide buttons on a tool bar into groups.

Used to display a "Tip" for a Component. Typically components provide api
to automate the process of using ToolTips.
For example, any Swing component can use the JComponent
setToolTipText method to specify the text
for a standard tooltip. A component that wants to create a custom
ToolTip
display can override JComponent's createToolTip
method and use a subclass of this class.

See How to Use Tool Tips
in The Java Tutorial
for further documentation.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

 A control that displays a set of hierarchical data as an outline.
You can find task-oriented documentation and examples of using trees in
How to Use Trees,
a section in The Java Tutorial.

A specific node in a tree can be identified either by a
TreePath (an object
that encapsulates a node and all of its ancestors), or by its
display row, where each row in the display area displays one node.
An expanded node is a non-leaf node (as identified by
TreeModel.isLeaf(node) returning false) that will displays
its children when all its ancestors are expanded.
A collapsed
node is one which hides them. A hidden node is one which is
under a collapsed ancestor. All of a viewable nodes parents
are expanded, but may or may not be displayed. A displayed node
is both viewable and in the display area, where it can be seen.

The following JTree methods use "visible" to mean "displayed":

isRootVisible()
setRootVisible()
scrollPathToVisible()
scrollRowToVisible()
getVisibleRowCount()
setVisibleRowCount()

The next group of JTree methods use "visible" to mean
"viewable" (under an expanded parent):

isVisible()
makeVisible()

If you are interested in knowing when the selection changes implement
the TreeSelectionListener interface and add the instance
using the method addTreeSelectionListener.
valueChanged will be invoked when the
selection changes, that is if the user clicks twice on the same
node valueChanged will only be invoked once.

If you are interested in detecting either double-click events or when
a user clicks on a node, regardless of whether or not it was selected,
we recommend you do the following:



final JTree tree = ...;

MouseListener ml = new MouseAdapter() {
    public void mousePressed(MouseEvent e) {
        int selRow = tree.getRowForLocation(e.getX(), e.getY());
        TreePath selPath = tree.getPathForLocation(e.getX(), e.getY());
        if(selRow != -1) {
            if(e.getClickCount() == 1) {
                mySingleClick(selRow, selPath);
            }
            else if(e.getClickCount() == 2) {
                myDoubleClick(selRow, selPath);
            }
        }
    }
};
tree.addMouseListener(ml);
NOTE: This example obtains both the path and row, but you only need to
get the one you're interested in.

To use JTree to display compound nodes
(for example, nodes containing both
a graphic icon and text), subclass TreeCellRenderer and use
setCellRenderer(javax.swing.tree.TreeCellRenderer) to tell the tree to use it. To edit such nodes,
subclass TreeCellEditor and use setCellEditor(javax.swing.tree.TreeCellEditor).


Like all JComponent classes, you can use InputMap and
ActionMap
to associate an Action object with a KeyStroke
and execute the action under specified conditions.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A subclass of TransferHandler.DropLocation representing
a drop location for a JTree.

DynamicUtilTreeNode can wrap
vectors/hashtables/arrays/strings and
create the appropriate children tree nodes as necessary. It is
dynamic in that it will only create the children as necessary.

Warning:
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 java.beans package.
Please see XMLEncoder.

EmptySelectionModel is a TreeSelectionModel
that does not allow anything to be selected.

Warning:
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 java.beans package.
Please see XMLEncoder.

The "viewport" or "porthole" through which you see the underlying
information. When you scroll, what moves is the viewport. It is like
peering through a camera's viewfinder. Moving the viewfinder upwards
brings new things into view at the top of the picture and loses
things that were at the bottom.

By default, JViewport is opaque. To change this, use the
setOpaque method.

NOTE:We have implemented a faster scrolling algorithm that
does not require a buffer to draw in. The algorithm works as follows:
The view and parent view and checked to see if they are
JComponents,
if they aren't, stop and repaint the whole viewport.
If the viewport is obscured by an ancestor, stop and repaint the whole
viewport.
Compute the region that will become visible, if it is as big as
the viewport, stop and repaint the whole view region.
Obtain the ancestor Window's graphics and
do a copyArea on the scrolled region.
Message the view to repaint the newly visible region.
The next time paint is invoked on the viewport, if the clip region
is smaller than the viewport size a timer is kicked off to repaint the
whole region.

In general this approach is much faster. Compared to the backing store
approach this avoids the overhead of maintaining an offscreen buffer and
having to do two copyAreas.
Compared to the non backing store case this
approach will greatly reduce the painted region.

This approach can cause slower times than the backing store approach
when the viewport is obscured by another window, or partially offscreen.
When another window
obscures the viewport the copyArea will copy garbage and a
paint event will be generated by the system to inform us we need to
paint the newly exposed region. The only way to handle this is to
repaint the whole viewport, which can cause slower performance than the
backing store case. In most applications very rarely will the user be
scrolling while the viewport is obscured by another window or offscreen,
so this optimization is usually worth the performance hit when obscured.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

  window.add(child);

A JWindow is a container that can be displayed anywhere on the
user's desktop. It does not have the title bar, window-management buttons,
or other trimmings associated with a JFrame, but it is still a
"first-class citizen" of the user's desktop, and can exist anywhere
on it.

The JWindow component contains a JRootPane
as its only child.  The contentPane should be the parent
of any children of the JWindow.
As a convenience, the add, remove, and setLayout
methods of this class are overridden, so that they delegate calls
to the corresponding methods of the ContentPane.
For example, you can add a child component to a window as follows:


      window.add(child);
And the child will be added to the contentPane.
The contentPane will always be non-null.
Attempting to set it to null will cause the JWindow
to throw an exception. The default contentPane will have a
BorderLayout manager set on it.
Refer to RootPaneContainer
for details on adding, removing and setting the LayoutManager
of a JWindow.

Please see the JRootPane documentation for a complete description of
the contentPane, glassPane, and
layeredPane components.

In a multi-screen environment, you can create a JWindow
on a different screen device.  See Window for more
information.

Warning: Swing is not thread safe. For more
information see Swing's Threading
Policy.

Warning:
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 java.beans package.
Please see XMLEncoder.

A KeyStroke represents a key action on the keyboard, or equivalent input
device. KeyStrokes can correspond to only a press or release of a particular
key, just as KEY_PRESSED and KEY_RELEASED KeyEvents do; alternately, they
can correspond to typing a specific Java character, just as KEY_TYPED
KeyEvents do. In all cases, KeyStrokes can specify modifiers (alt, shift,
control, meta, altGraph, or a combination thereof) which must be present during the
action for an exact match.

KeyStrokes are used to define high-level (semantic) action events. Instead
of trapping every keystroke and throwing away the ones you are not
interested in, those keystrokes you care about automatically initiate
actions on the Components with which they are registered.

KeyStrokes are immutable, and are intended to be unique. Client code cannot
create a KeyStroke; a variant of getKeyStroke must be used
instead. These factory methods allow the KeyStroke implementation to cache
and share instances efficiently.

Warning:
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 java.beans package.
Please see XMLEncoder.

A SortingFocusTraversalPolicy which sorts Components based on their size,
position, and orientation. Based on their size and position, Components are
roughly categorized into rows and columns. For a Container with horizontal
orientation, columns run left-to-right or right-to-left, and rows run top-
to-bottom. For a Container with vertical orientation, columns run top-to-
bottom and rows run left-to-right or right-to-left. See
ComponentOrientation for more information. All columns in a
row are fully traversed before proceeding to the next row.

LayoutStyle provides information about how to position
components.  This class is primarily useful for visual tools and
layout managers.  Most developers will not need to use this class.

You typically don't set or create a
LayoutStyle.  Instead use the static method
getInstance to obtain the current instance.

public Component getListCellRendererComponent(JList<?> list,
                                              Object value,
                                              int index,
                                              boolean isSelected,
                                              boolean cellHasFocus) {

    setText(value.toString());

    Color background;
    Color foreground;

    // check if this cell represents the current DnD drop location
    JList.DropLocation dropLocation = list.getDropLocation();
    if (dropLocation != null
            && !dropLocation.isInsert()
            && dropLocation.getIndex() == index) {

        background = Color.BLUE;
        foreground = Color.WHITE;

    // check if this cell is selected
    } else if (isSelected) {
        background = Color.RED;
        foreground = Color.WHITE;

    // unselected, and not the DnD drop location
    } else {
        background = Color.WHITE;
        foreground = Color.BLACK;
    };

    setBackground(background);
    setForeground(foreground);

    return this;
}

Identifies components that can be used as "rubber stamps" to paint
the cells in a JList.  For example, to use a JLabel as a
ListCellRenderer, you would write something like this:


class MyCellRenderer extends JLabel implements ListCellRenderer<Object> {
    public MyCellRenderer() {
        setOpaque(true);
    }

    public Component getListCellRendererComponent(JList<?> list,
                                                  Object value,
                                                  int index,
                                                  boolean isSelected,
                                                  boolean cellHasFocus) {

        setText(value.toString());

        Color background;
        Color foreground;

        // check if this cell represents the current DnD drop location
        JList.DropLocation dropLocation = list.getDropLocation();
        if (dropLocation != null
                && !dropLocation.isInsert()
                && dropLocation.getIndex() == index) {

            background = Color.BLUE;
            foreground = Color.WHITE;

        // check if this cell is selected
        } else if (isSelected) {
            background = Color.RED;
            foreground = Color.WHITE;

        // unselected, and not the DnD drop location
        } else {
            background = Color.WHITE;
            foreground = Color.BLACK;
        };

        setBackground(background);
        setForeground(foreground);

        return this;
    }
}

This interface defines the methods components like JList use
to get the value of each cell in a list and the length of the list.
Logically the model is a vector, indices vary from 0 to
ListDataModel.getSize() - 1.  Any change to the contents or
length of the data model must be reported to all of the
ListDataListeners.

This interface represents the current state of the
selection for any of the components that display a
list of values with stable indices.  The selection is
modeled as a set of intervals, each interval represents
a contiguous range of selected list elements.
The methods for modifying the set of selected intervals
all take a pair of indices, index0 and index1, that represent
a closed interval, i.e. the interval includes both index0 and
index1.