Java Swing, 2nd Edition

Conventions

This book follows certain conventions for font usage, property tables, and class diagrams. Understanding these conventions up-front makes it easier to use this book.

This book uses the following font conventions:

Italic

Used for filenames, file extensions, URLs, application names, emphasis, and new terms when they are first introduced

Constant width

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

Constant width bold

Used for commands you enter at the command line and to highlight new code inserted in a running example

Constant width italic

Used to annotate output

Tip

This icon designates a note, which is an important aside to the nearby text.

Warning

This icon designates a warning relating to the nearby text.

Properties Tables

Swing components are all JavaBeans. Properties provide a powerful way to work with JavaBeans, so we use tables throughout the book to present lists of properties. Table P-3 is an example from the hypothetical JFoo class that shows how we use these tables.

Table P-3. Properties of the fictional JFoo class

Property	Data type	get	is	set	Default value
opaque b, o, 1.4	boolean	·	·	·	true
bbound, ooverridden, 1.4since 1.4 See also properties from the JComponent class (Table 3-6).

Properties tables tell you the data type; whether it has is, get, and set methods; and its default value, if any. Footnotes to the properties tables tell you, among other things, whether a property is bound, protected, indexed, and/or overridden. We use “overridden” to mean both actual overridden methods in the case of a concrete parent class and implemented methods in the case of an abstract parent class or an interface. If it is a recent addition, the version of the SDK that added the property is noted (assume 1.2 if there is no footnote).

Table P-3 indicates that a JFoo object has a read/write bound property named opaque with the data type boolean. The property was introduced in the 1.4 release of the SDK. 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 opaque is a bound property, changing its value generates a PropertyChange-Event. The overridden footnote indicates that the opaque property is also inherited (or possibly implemented for the first time); it is listed here because the JFoo class has altered the property in some way—e.g., the default value was changed, accessor methods were added, or new behavior when accessing or modifying the value was specified. A cross-reference following the table says that JFoo has inherited properties from the JComponent class; see the discussion of that class for details on these properties.

We’ve listed default values for properties wherever applicable. (Properties of interfaces, for example, will not have any values listed.) To save space, we omit the new operator in these tables.

One more note about bound properties. The Swing developers introduced some confusion into the notion of a “bound property” by adding a new lightweight event, ChangeEvent, which is a stateless version of PropertyChangeEvent. In these tables, we adhere strictly to the JavaBeans definition of a bound property: modifying a bound property generates a PropertyChangeEvent.

Class Diagrams

The class diagrams that appear throughout the book are similar to those in Learning Java and other Java books from O’Reilly. Solid lines indicate inheritance relationships; dotted lines indicate interface relationships. In Figure P-1, 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 with an A icon.

We also use the class diagrams to show information about relations between classes. In Figure P-1, 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 P-1. Class diagram notation