In 1997 there was an explosion of third-party tools for Java. A variety of integrated development environments (IDEs), class libraries and visual components became available. Web sites that review and catalog Java tools like Gamelan (http://www.developer.com/directories/pages/dir.java.html) and JARS (http://www.jars.com) saw their listings swell. So, what was the key factor that led to this growth? JavaBeans.

JavaBeans is the Java component architecture standard. It allows developers to create components and expose their capabilities in a consistent, standardized manner. JavaBeans is in many ways comparable to other component architectures, like Microsoft's COM/OLE/ActiveX for Windows. Unlike OLE, however, it is specific to one language, Java, and not to any one operating system.

The JavaBeans specification was announced by Sun at the first JavaOne conference in May of 1996. The announcement came along with announcements for a number of other APIs - the Media APIs (Java 2D, Java 3D), RMI, Security, Commerce - but JavaBeans was the focus of most of JavaSoft's initial development effort. The JavaBeans specification was completed ahead of schedule (October '96) and was released to the world as part of the Java 1.1 core API in February 1997. From the amount of effort JavaSoft put into it, it was obvious that they felt that a robust, well-designed component architecture was key to Java's future success.

The inclusion of JavaBeans as a core Java API has opened the door to the third-party components market. All of the major Java IDE vendors have made Beans support an integral part of their strategies. Beans gives the IDEs the ability to deal with components, both visual and non-visual, in a standard way based on core Java APIs. Any one of the IDEs could have come up with a specification like JavaBeans by themselves, but the fact that Beans is a standard, core API makes it more attractive than a proprietary, single-vendor solution. With the availability of an open component standard that was supported in multiple IDEs, component vendors rushed to adopt Beans. Although none of the IDEs support every JavaBeans feature, the level of support is amazing for a language that's just approaching its third birthday. JavaBeans has been a big win for IDE and tool vendors but ultimately the biggest win is for developers who can feel free to choose their tools and development environments without worrying whether or not they'll all work together.

While JavaBeans has been great so far, it isn't finished by any means. The 'Glasgow' specification maps out the immediate future for Beans with three much needed additions to the specification: the Containment and Services protocol, the drag and drop API and the JavaBeans Activation Framework. These new pieces of functionality, most of which will be provided in the upcoming Java 1.2 release, will make Java an even more compelling platform for application developers.

The ability to do integrated drag and drop operations with the desktop OS, the ability for Beans to interact better with other tools at design time (via the Containment and Services protocol) and the ability for Java programs to exchange self-describing data objects will attract more and more developers, perhaps even pulling some of them away from more established RAD software building tools.

There's still more that needs to be done after 'Glasgow' though. Part of the original specification was an object aggregation and delegation model that would allow bean developers to construct Beans out of other Beans with a standard way to expose the internal Beans to the outside world. This would allow Bean vendors to create beans that are more powerful, yet simpler to use and understand. Another major change that should be made is that in order to support this sort of functionality, IDEs are going to have to move away from their current methods of handling JavaBeans through code generation alone and add a serialization-based mechanism in order to support a number of the JavaBean features that they're currently missing, like support for Bean customizers. A number of JavaBean vendors have been pushing for this change, but the IDEs haven't shown any signs of moving yet.

Overall, JavaBeans has been the most important new API to come along for Java since the initial Java 1.0 release. In the three years since its release, Java has gone from being an interesting toy language to a serious, industrial-strength development platform largely because of the capabilities offered by JavaBeans. If you're not using JavaBeans in your Java development, ask yourself - why not?