Digging Deeper into JavaBean Technology

Continuing what we started last week, we're delving deeper into the features of the JavaBeans Development Kit.

We've talked so far about what the system is, and what it is used for. Summing up again (because there's a surprising dearth of people whom really know what component software does, despite the number that talk about it), a JavaBean environment is simply an agreement by all parties following the Java API to write some of their objects in a certain way--one that allows easy, and in some cases, "automatic," use with other objects.

We showed last week how a simple "Bean environment" could be used to graphically connect the occurrence of an Event in one Bean to the execution of a Method on another. When we say graphically, we mean by way of the mouse, and when we say "Bean environment," we're really talking about a prototypical Java application written to allow us to test most of the features of the system (the BeanBox). We can imagine that many of the development environments written to take advantage of the JavaBeans standard will operate in a vaguely similar fashion.

As you may have guessed, connecting Events to Methods in this rather sophomoric fashion is just a very basic example. We'll begin to talk about more of the features of the standard shortly; right now, let's look at what, exactly, makes a JavaBean. How hard is it to write one?

If you're as suspicious as we were about the difficulty of this, prepare to be surprised. Once again, Javasoft delivered a system where only complicated intentions lead to a lot of typing. When we came to the part of the Beans Tutorial describing the creation of a simple JavaBean, we were pleasantly surprised to discover that the Bean class itself was exceedingly simple. In fact, it's almost exactly like a regular class.

There are two distinguishing features of the basic Bean. The first (and primary) one is organizational; JavaBeans (at least for purposes of the BeanBox, or other development tools) are organized in packages and kept in JAR files. These, in addition to the beans themselves, can contain a small text file to speed identification of its contents, which looks something like this:

Name: sunw/demo/bean/BeanName.class
Java-Bean: True

It's a potential minor inconvenience, but we suppose forgivable. For purposes of the BDK, JAR files are kept in a specific directory (for automatic inclusion in the BeanBox toolbar of available Beans).

The second is probably a more passing requirement. The current BeanBox is not yet prepared to support nonvisible Beans, so for the moment, in order to use this diagnostic tool, your beans must give you something to look at (i.e., be a part of the AWT in some way), and preferably specify a minimum size requirement. Most any AWT object does so by simply having a getMinimumSize method to return the Dimension requirements you specify.

The example in the Tutorial is just a class (part of an arbitrary package) that extends a Canvas, paints itself red when it instantiates, and requests its minimum size to be 50 by 50 pixels. When placed in a JAR file with a description file, it's ready for use in the BeanBox.

It's important to notice exactly how delicate are the restraints of the JavaBean system. The requirement of visibility is a transient one owing to the incomplete state of the BeanBox, and will rapidly be moot. The requirement to be packaged in a JAR file (with the already optional description file) is generally not a requirement; it's simply a "common" convention Sun has "suggested" for distribution of individual Beans. Obviously, a finished application using Beans may contain them any way it likes.

The last requirement, that Beans be part of a package, is perhaps the most solid, and even this is somewhat ephemeral--it's there because, without a good, large system for naming everything, a component architecture doesn't make organizational sense. Finally, all that remains is that almost any class is potentially a Bean, without any effort on your part at all--another fairly elegant solution in Sun's quest to make the simple effortless and the complex possible.

But what about the complex? Next week, we'll move beyond the minimum requirements and get into more of the advanced capabilities of JavaBeans.

Past installments of Java Jolt