What's a JavaBean? (And when will we stop with all the coffee puns?)

[hassen1]

Of all of the features of JDK 1.1, JavaBeans has probably received the most attention and is the source of the most confusion. Beans began in response to the problems of writing a visual application builder for Java, like the one in SGI's own Cosmo Code. Builders work with object classes, presenting users with properties they can modify and events on one object that they can tie to methods on another object. Ideally, a builder should be able to import new classes, glean all of the property, event and method information and then allow them to be manipulated in the same way as built-in classes.

It turns out that much of the information needed by the builder is available in the class file. It is relatively easy to determine the methods a class supports and to distinguish methods that retrieve state from those that modify state: Does the method accept arguments? It's a set method. Does it return a value? It's a get method. (Does it do both? Ignore it and maybe it'll go away.)

We can identify set and get methods by inspection of the class file. But one thing we can't always do is match up set methods with their corresponding get methods. For example, in JDK 1.0 an AWT component implements a get method called location which returns the component's position as a Point object. But the corresponding set method is called move. And instead of taking a Point, move represents the new position as a pair of ints. If people would be consistent in their naming (a setLocation method that accepts a Point; a getLocation method that returns one), it would make life a lot easier for builders and the people who write them.

JavaBeans contains just such a method naming convention as part of its specification. It defines a concept called a property; if a class defines both setLocation and getLocation methods that accept and return a Point, then that class can be said to have a property called Location whose type is Point. A builder would be able to learn all this not by reading the class file, but instead by using the Beans API to ask the class for the information. It can get the list of properties, data fields, constructors and other methods, along with their argument lists and return types. It can also get a list of event types generated by a class, so it can provide linkage between an object's events and the object that should respond to it.

A class can also define a customizer. A customizer provides a UI for changing an object's value. For example, a customizer for the Point class might present a pair of text fields where we could type integer values for X and Y. Or it might present a pair of scroll bars or a canvas in which we would click the mouse to specify a position. The Customizer interface frees the builder from having to define editors for all of the possible objects that might be imported into it. New object classes define their own editors, which the builder can embed in its property sheets. Inside the builder, any object that contains a Point would use the Point's customizer to edit it.

Although JavaBeans' most immediate value is in integrating new components into application builders, its designers have much more in mind for the technology. They are also touting Beans as an architecture for linking components dynamically. Instead of a class learning about and binding to another class's interface at compile time, it could query the class at run time, learn about the supported methods and decide how to integrate with it. In this way, Beans becomes a partner with and a competitor to technologies like Microsoft's COM/OLE/ActiveX or Apple's OpenDoc.

How serious a player Beans will be in the component architecture arena remains to be seen. But it is already being integrated into environments based on distributed components. JavaSoft has already discussed integration of JavaBeans with CORBA. Can Microsoft's DCOM (Distributed Component Object Model) be far behind?