Inside the JavaBeans Developer Kit

This week, as promised, we're going to take an inside look at the JavaBeans Developer Kit and report on what we find.

Afterall, experimenting with JavaBeans is the only sensible way to really understand what they're good for. We've satisfied you with general terms for long enough. Now is the time, if you have liberty to do so, to set up a simple workshop for experimenting with Beans.

Download an acceptably recent version of the JDK, install it, then download the "BDK" and install that. As of this writing, there are versions of all available for Windows95/NT and Solaris 2.4/2.5. Make sure that your search path contains the Java binaries (this is accomplished differently from individual system to individual system).

Currently, the tutorial comes included only in Acrobat and Postscript formats, so ready your viewer of choice. The first chapter is relatively non-threatening to amateurs, and is also the most important in forming a basic understanding of what JavaBeans are really doing for us.

What magic is component software really supposed to make? Why has it continually seeded claims that software can be produced "automatically" with only the use of a mouse? In fact, there is something interesting here, though people frequently claim far more of it than it deserves. But don't take our word for it; see for yourself what the hype really amounts to. The basic source of the component software myth is present in the "BeanBox"--a simple Bean test program written in Java and included with the BDK.

This is the centerpiece of the Beans Developer Kit, which, by deceptively resembling the Java Developer Kit in name, might seem to imply that some special software is required to make Beans work. Not true, of course; the JavaBeans standard exists entirely in th e new API. It is only a general standard telling precisely how objects may describe their properties and behaviors, and when they adhere to it, Java applications like the BeanBox can work.

The BeanBox (which is currently followed up by a host of other development environments that support JavaBeans) has power which is best summed up in the example we're directed to by the JavaBeans Tutorial.

You can place an animated icon on the blank workspace by clicking on its name in the toolbar and clicking on a blank spot in the BeanBox window. It will appear with animation underway. You can then also place buttons on the workspace in the same manner. This is nothing very special so far, just a glorified interface builder. But with the BeanBox, you can symbolically connect the occurrence of an Event on a button Bean to the performance of a method on the animation Bean by selecting the button, picking the event out of the Edit menu, connecting a red line from the button to the animator with the mouse, and then selecting the method you want to set off from a list.

In this example, a button (which we can label "Start" just by typing it into a field in a "property" window) has it's actionPerformed event connected to the method in the animator Bean which starts the animation sequence. Vice versa for a "Stop" button. Clicking on the Start button now makes the animation start, and clicking on the Stop button now makes the animation stop. All this, with only one hand.

The obvious implication is that JavaBeans can make it easier to assemble controls for applications much more complex than a simple animated display. We won't claim that this makes programming go away, but it does allow already completed software efforts to be interconnected far more easily. We doubt this will ever be so easy that laymen will be lining up to do it, but the standards and the process can save developers appreciable time and effort.

Next week, we'll explore more of the capabilities of the Beans standard, and go deeper into the potentials of the BeanBox and its ilk.

Past installments of Java Jolt