The goal of the JavaBeans APIs was to define a software component model for Java, so that third party Independent Software Vendors (ISVs) could create and ship Java components that can be composed together into applications by end users.

The promise behind JavaBeans was to revolutionize software development allowing the non-programmers (possibly even PHBs) to develop a spectrum of applications that previously would have been programmers’ domain – just as spreadsheets allowed in the 80-ies. Although Sun has succeeded in creating a specification that could fulfill this purpose, it has yet to gain widespread acceptance, as the only Interactive Development Environment (IDE) supporting Visual Programming is IBM’s Visual Age for Java (and even it lacks certain features that are crucial to allow true visual development).

Therefore, JavaBeans are mostly interesting to the enterprise developer in a sense that they are a more modular way of code reuse than code libraries. It may be a very good idea to always search for a JavaBean to reuse before writing a generic component and always package a generic component as a JavaBean, if time permits. In addition, certain other Java technologies, such as JSPs integrate well with JavaBeans.

There is a range of different kinds of JavaBeans components:
a. Some JavaBean components are used as building blocks in composing applications. Therefore, a user may be using some kind of builder tool to connect together and customize a set of JavaBean components to act as an application. Thus, for example, an AWT button would be a Bean.
b. Some JavaBean components will be more like regular applications, which may then be composed together into compound documents. So, a spreadsheet Bean might be embedded inside a Web page.

These two aspects overlap. For example, a spreadsheet might live within a composite application as well as within a more normal compound document. So there is more of a continuum than a sharp cutoff between “composite applications” and “compound documents”.

Although Sun’s JavaBeans specification defines a Java Bean as “a reusable software component that can be manipulated visually in a builder tool”, from the technical standpoint a JavaBean is just a Java class (possibly, accompanied with editor and bean information classes) that follows certain guidelines.

Individual Java Beans vary in the functionality they support, but the typical unifying features that distinguish a Java Bean are:
- Support for “introspection” so that a builder tool can analyze how a bean works.
- Support for “customization” so that when using an application builder a user can customize the appearance and behavior of a bean.
- Support for “events” as a simple communication metaphor than can be used to connect beans.
- Support for “properties”, both for customization and for programmatic use.
- Support for persistence, so that a bean can be customized in an application builder and then have its customized state saved away and reloaded later.

Log in or register to write something here or to contact authors.