Java Programming, Lecture Notes # 1010
August 7, 2000
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. 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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
-end-