Java's Magic Beans
-- Angus Graham
Java Beans are often heard about, but many people don't really know what they are
exactly. I had been developing in Java for a little over a year before I ever found
out what they were and what they were for. This article should help you become
familiar with what beans are, and why they are used.
Beans are found nearly everywhere in Java. The AWT classes are beans. Any
expansion classes such as JFC are usually found as beans. A lot of software
developers also spend time developing beans. So what are these beans? The official
definition of a Java Bean according to JavaSoft is "a reusable software component
that can be manipulated visually in a builder tool". The Java Beans
architecture follows the component model described below.
The Component Model
A component is a software element that has all the data components, and the procedures
needed to provide a particular service. For example a combo box could be a
component. It provides the service of giving a list of choices to the user and
letting him select one. These components are assembled together to create a software
application.
Components have 3 different types of attributes:
- Properties - These describe what the bean is. The programmer can get and
set the values of properties.
- Methods - These are what the bean can do. The programmer can call these
methods to cause the component to do something or to receive information about the
component.
- Events - These are actions the bean knows about.
For example a radio button component could have a property Text describing the text
that appears next to it. It could also have a method called IsSelected to determine
if that radio button is currently selected. It would also probably recognize a Click
event to determine when it has been clicked by the user. Of course it would probably
have many more properties, methods, and events than just these three.
They also have to conform to a few other requirements. For instance components
also must be able to send and receive events to and from each other. This is how
they communicate.
The bean is simply a standard format for representing components so all component-based
Java editors will be able to recognize and handle them with equal ability. Beans are
written entirely in Java, and have no new syntax so they are fully compatible and portable
with any platform of Java 1.1 or higher.
How Beans are Written
There are two ways you can turn your code into a Java Bean. The first, and
possibly the simplest, is to simply follow the bean design pattern. This design
pattern is not to be confused with the design patterns often heard about in object
oriented theory. In this case, a design pattern is really not much more than strict
naming conventions for methods and event handlers. Some prefer to call these naming
patterns to avoid confusion with object oriented design patterns. I won't get into
all the naming patterns here since they can all be found in any good book explaining beans
or probably in any number of sites on the web.
Here's a short example to demonstrate the concept. Suppose you want to create a
Bean with properties (pretty much all Beans have properties). In this case you
format your code so that all methods used to set a property have the name setPropertyname,
etc. Then the properties and methods of the component are discovered through
introspection, which means that the code is examined, and because the code follows the
bean pattern, properties and methods can be found and exposed automatically by the
builder.
For example:
Protected int Temp;
public void setTemperature(int newTemp) {
Temp = newTemp;
}
public int getTemperature() {
return Temp;
}
This simple piece of code will create a property called Temperature. Because both
a getTemperature method and a setTemperature method exist, the introspection mechanism
will see this and know that the component should have a property called Temperature
exposed. If the bean is loaded into any Java GUI editor such as Visual Age for Java
or Visual Café, the property editor for this component will show a Temperature property.
It will also know that Temperature is an integer and will again automatically use
the integer property editor when the programmer wants to change the value of Temperature.
A bean should always implement the Serializable interface in order for it to be
persistent. Persistence means that you can change the value of a property of a Bean,
and the new state will be saved. Then when the Bean is loaded at a different time,
the property will still have its state set to the changed value.
As with all Java classes, a Java Bean extends a class that already exists. If a
class’ code does not explicitly extend a class, then it implicitly extends the Object
class. Since not all beans will have a visual representation during run-time, not
all beans have to extend the Component class. Beans that will have a visual
representation during run-time do of course, but beans which won't, can extend implicitly
from Object.
The BeanInfo Class
Following naming patterns is very simple, but the problem is it doesn't work all the
time. Not that the mechanism doesn't work, but sometimes the bean we are creating is
too complex to have all its features properly revealed using naming patterns. There
is a solution, which is to create a BeanInfo class for your bean.
A BeanInfo class is a class that gives detailed information about your bean.
First a class is created which implements the BeanInfo interface. The class
name must be the name of your bean followed by BeanInfo. For example the bean Jelly
would have a BeanInfo class called JellyBeanInfo describing the Jelly Bean.
You probably won't want to write a full class from scratch that implements the BeanInfo
interface, so instead you can have your class extend the SimpleBeanInfo class. This
class returns null for all the methods in the BeanInfo interface. All that needs to
be done is to rewrite the methods that need to be changed.
JAR Files
When you're through with creating your beans, you'll probably want to store them in a
JAR file. For those of you not sure about JAR files, a JAR file is a Java Archive
file. These JAR files are used to store Java class files and other resources.
A JAR can be created for your classes using the command:
jar cf JARfilename bean1 bean2 bean3...
Once your beans are in the JAR format, they can be imported into visual Java editors.
ActiveX Compatible?
Microsoft’s ActiveX, like Java Beans, is also a component architecture. It
is used on pretty much all Windows machines. Java beans are not by themselves
ActiveX compatible. However Sun has developed a software bridge, which allows beans
to be imported into ActiveX applications. This means that a Visual Basic programmer
could use beans developed in Java, without having to make any change to the format at all.
The ActiveX Bridge can be found at JavaSoft’s web site at http://java.sun.com.
Beans are not just used for GUI components. They can be used to create any sort
of component you want to manipulate in a visual builder, regardless of whether the
component draws anything on the screen at run-time. Here’s an interesting
application illustrating that. Say I am developing a simulation of multiple nodes
communicating with each other. I can build a node component using Java Beans.
Then when I build my simulation, I can drag and drop as many nodes as I need into
my application, and set each node’s properties using the built-in visual property
editor. This makes it very simple for you or others to change the parameters of the
simulation by easily being able to edit, add, or remove nodes.
The main idea behind beans is to have components that you can reuse over and over, and
make them available to be manipulated using a visual Java editor. Because of this,
they are not something every Java developer would use. Not all developers are
interested in making all parts of their code reusable, and some developers never use
visual editors to do their programming. But for those who do use visual editors and
find it important to have reusable components, beans definitely make their lives a lot
easier.
References
Englander, Robert, "Developing JavaBeans".
O'Reilly and Associates, USA, 1997
Horstmann, Cay S. and Cornell, Gary, "Core Java - Volume II: Advanced
Features". Sun Microsystems Press, California, 1998
Java Beans, java.sun.com/beans
java.sun.com/beans/docs/spec.html
|
