- Preface
- Introduction
- JavaBean Component Design Patterns
- JComponent Properties
- Container and Component Properties
- Property Names
- JComponent Events
- Container and Component Events
- Exposed Methods of JComponent
- Summary
- Where To From Here?
Preface
Recommended supplementary reading
It is recommended that in addition to studying this set of lessons, you also study my earlier lessons on Swing. A list of some of my Swing lessons can be found in an earlier lesson in this series:
Swing from A to Z: Some Simple Components
Links to the lessons themselves can be found at Baldwin’s Java Programming Tutorials.
The earlier lessons will introduce you to the use of Swing while avoiding much of the detail included in this series.
Introduction
Apply to Swing components as a group
This is important because most Swing components extend JComponent either directly or indirectly. Thus, these properties, events, and methods apply to most of the components in Swing. We can learn about them as a group instead of having to learn about them on an individual component basis.
Each component can have other properties, events, and methods
In addition, individual Swing components can have other properties, events, and methods defined in subclasses of JComponent. We will deal with those properties, events, and methods on an individual component basis later in this series of lessons.
Lesson will identify properties, events, and methods
This lesson will identify the properties, events, and methods that Swing components inherit from JComponent and its superclasses. Subsequent lessons will discuss and illustrate many of them.
JavaBean Component Design Patterns
Explained design patterns in earlier lessons
I’m not going to explain design patterns here, because my earlier lessons on JavaBeans provide a complete explanation of design patterns. Rather, I am simply going to use design patterns to identify and list the properties, events, and methods of JComponent and its superclasses.
If you are not familiar with Design Patterns in JavaBeans, see my earlier lessons on beans, which you will find at Baldwin’s Java Programming Tutorials.
JComponent Properties
Figure 1
shows the accessor methods for the properties that are defined in the JComponent class.
Inherited by most Swing components
The properties in
Figure 1
are inherited by most Swing components.
Some are shown in red
A few of the properties are shown in red in
Figure 1
. The properties shown in red are not defined in JComponent, but rather are inherited from the Component class. They are included in
Figure 1
for completeness. In each case, they form the other half of a setter-getter method pair. (See my earlier lessons on JavaBeans if the setter-getter terminology is new to you.)
Container and Component Properties
Figure 2
shows the accessor methods for the properties defined in the Container and Component classes that are not overridden in the JComponent class. Container properties are shown in blue. Component properties are shown in red.
Also inherited by Swing components
Because JComponent extends Container, which extends Component, most of the Swing components inherit these properties as well. Hence, these properties also define the default behavior and appearance of most Swing components.
Property Names
Name is based on name of method
The official name of a property is that portion of the name of the accessor method following set, get, or is, with the case of the first character changed to lower case. (There are also some special cases involving upper case and lower case that I won’t discuss here.)
A property named visible
For example, the following two accessor methods refer to a property named visible.
- boolean isVisible()
- void setVisible(boolean aFlag)
You can call the first method to read the current value of the property, and you can call the second method to write a new value into the property.
JComponent Events
Default event types identified in JComponent and its superclasses
The default event types are defined by the JComponent, Container, and Component classes. Other event types that are specific to individual Swing components may be defined in subclasses of JComponent.
Event types match registration methods
We can identify the default event types by identifying the event registration methods in the JComponent, Container, and Component classes. These registration methods are inherited by most Swing components.
Registration method names
According to JavaBean design patterns, the type of the event can be identified by the word(s) appearing between add and Listener in the name of the registration method.
A PropertyChange event
For example, the existence of a registration method named addPropertyChangeListener() indicates the ability to multicast an event of the PropertyChangeEvent class.
The method name also indicates the availability of an interface named PropertyChangeListener. This interface must be implemented by classes from which listener objects for this type of event are instantiated.
JComponent events
Figure 3
shows the event registration methods that are defined in the JComponent class.
Because most Swing components extend this class, they are able to multicast events of these types.
Container and Component Events
Figure 4
shows the event types for which registration methods are defined in the Container and Component classes.
Because most Swing components extend these classes indirectly, they are able to multicast events of these types also.
Events defined in the Container class are shown in blue. Events defined in the Component class are shown in red.
Events familiar to AWT programmers
If you are already familiar with the use of event-driven programming using the Delegation Event Model and the AWT, you should already be familiar with all but one of these event types. (If not, see my tutorial lessons on the Delegation Event Model.)
One new event type
The one event type that may not be familiar to you is the InputMethod event.
According to one of my favorite authors, David Flanagan, “Application-level code should never have to use this class.”
He also states “Application-level code should never have to use or implement this interface.”
If you would like to know more about his reasoning, see his book entitled Java Foundation Classes in a Nutshell, published by O’Reilly.
Exposed Methods of JComponent
Swing components have this behavior unless they override
All Swing components that extend JComponent either directly or indirectly will exhibit this default behavior unless they override the methods to provide behavior that is more appropriate for those components.
Figure 5
lists the public methods of the class JComponent that are not included in one of the previous lists. These are the public methods of the JComponent class that are not accessor methods for properties, and are not registration methods for events.
Exposed methods
Many Swing components expose the methods in
Figure 5
to the outside world as a result of extending the JComponent class.
JavaBean introspection
For example, these are the methods that a JavaBeans introspection process (based on design patterns) would consider available for invocation by other beans.
Some are overridden methods
Some of the methods in
Figure 5
are overridden versions of methods originally defined in Container, Component, or Object. They have been overridden to cause their behavior to be more appropriate for Swing components.
Others are new methods
Other methods in
Figure 5
are new methods designed to provide new behavior for Swing components.
Some will be overridden later
Some of the methods in
Figure 5
are overridden further down the inheritance hierarchy in the classes from which specific Swing components are instantiated. In those cases, they are overridden to make the behavior more appropriate for those specific components.
Those not overridden define default behavior
However, many of them are not overridden, and those that are not overridden define default behavior for many Swing components.
Numerous other methods are inherited also
There are numerous other methods that Swing components inherit from Container, Component, and Object and expose to the outside world. However, since they are not specific to Swing, I haven’t listed them here.
Summary
Will use in subsequent lessons
This information will be used in subsequent lessons that discuss appearance and behavior that is common to many Swing components.
Useful to understand common behavior
It is useful to understand the appearance and behavior that is common to many Swing components before getting into the details of appearance and behavior that are specific to individual components.
Learning the common behaviors first can greatly accelerate the learning process.
Sun documentation is the final authority
Please note that all of this information was extracted from the documentation for JDK 1.2.2 from Sun.
Extracting the information was a tedious process, and it is possible that I may have made some mistakes.
In the event of any conflict between what I have presented here and the Sun documentation, you should consider the Sun documentation to be the final authority.
Where To From Here?
Copyright 2000, Richard G. Baldwin. Reproduction in whole or in part in any form or medium without express written permission from Richard Baldwin is prohibited.
About the author
Richard Baldwin is a college professor and private consultant whose primary focus is a combination of Java and XML. In addition to the many platform-independent benefits of Java applications, he believes that a combination of Java and XML will become the primary driving force in the delivery of structured information on the Web.
Richard has participated in numerous consulting projects involving Java, XML, or a combination of the two. He frequently provides onsite Java and/or XML training at the high-tech companies located in and around Austin, Texas. He is the author of Baldwin’s Java Programming Tutorials, which has gained a worldwide following among experienced and aspiring Java programmers. He has also published articles on Java Programming in Java Pro magazine.
Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.
