Java Swing

Conventions

The following font conventions are followed throughout this book:

Italic

is used for filenames, file extensions, URLs, application names, and emphasis.

Constant width

is used for Java class names, functions, variables, components, properties, data types, events, and snippets of code that appear in text.

We use tables throughout the book to present lists of properties (as defined by the JavaBeans specification). Here’s an example from the hypothetical JFoo class that shows how we use these tables:

Table 1. Properties of the Fictional JFoo Class

Property	Data Type	get	is	set	bound	Default Value
See also properties from the JComponent class (Table 3.5).
	opaque*	boolean	•	•	•	•	true

This table indicates that a JFoo object has a read/write bound property named opaque, with the data type boolean. This property has accessor methods with the signatures:

public boolean getOpaque();
public boolean isOpaque();
public void setOpaque( boolean opaque );

These methods aren’t listed separately when we discuss the class’s other methods. Because this is a bound property, changing its value generates a PropertyChangeEvent. JFoo has also inherited properties from the JComponent class; see the discussion of that class for these properties. The asterisk after the property name indicates that the opaque property is also inherited; it is listed here because the JFoo class has changed the behavior of the property in some way—either by adding accessor methods or changing the default value.

We’ve listed default values for properties wherever applicable. To save space, we abuse Java’s syntax slightly and omit the new operator in these tables.

The Swing group has introduced some confusion into the notion of a “bound property” by adding a new lightweight event, ChangeEvent, that is a stateless version of the PropertyChangeEvent. In these tables, we adhere strictly to the JavaBeans definition of a bound property: modifying a bound property generates a PropertyChangeEvent. Properties that generate a ChangeEvent are noted in the “Events” sections.

In some of the property tables, we’ve separated out some special properties that are particularly important in terms of the model-view-controller architecture. These properties are UI, UIClassID, and model properties, such as model and document.

The class diagrams that appear throughout the book are similar to the ones used in Java in a Nutshell and other Java Series books from O’Reilly. Solid lines indicate inheritance relationships; dotted lines indicate interface relationships. In the following figure, ClassA extends AbstractClass, which implements InterfaceX. There are two interface relationships that we don’t show in this way. All Swing classes implement Serializable, and showing this relationship explicitly would clutter the diagram; just assume that any Swing class implements Serializable, unless stated otherwise in the text. Many Swing classes implement the Accessible interface; rather than cluttering the diagrams, we show that a class implements Accessible by putting an A in the upper-right corner of a box.

We also use the class diagrams to show information about relations between classes. In the figure, the long-dashed arrow indicates that ClassA uses ClassB. The label on the arrow indicates the nature of the relationship; other common relations are “contains” and “creates”. 1..* indicates the multiplicity of the relationship. Here, an instance of ClassA uses one or more instances of ClassB. Other multiplicities are 1 (exactly one instance), 0..* (any number of instances), and 0..1 (zero or one instance).

Figure 1. Class diagram notation