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). | ||||||
|
|
• |
• |
• |
• |
|
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).
Get Java Swing now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.