What is a Java Bean?

A Java Bean is a reusable software component that can be manipulated visually in a builder tool.

What do we mean by a component? In general, components are self-contained elements of software that can be controlled dynamically and assembled to form applications. Component software environments (or what Sun refers to as builder tools), along with object-oriented techniques, allow applications to be built using a building-block approach. For such an approach to work, components must interoperate according to a set of rules and guidelines, and must behave in ways that are expected. (If you've built forms in Microsoft Access, you've used this visual building-block approach when you've dropped a list box (component) onto a form, and dragged its corners to change its size, or assigned a new font using its property sheet.)

The JavaBeans architecture brings this component model to Java.

Not all beans are alike. Beans can be simple GUI elements, like buttons, or more sophisticated software components, like spreadsheets. Many beans will have a GUI representation, but some are not visible; it is not a requirement that beans have a visual aspect at run-time. And although beans are targeted at builder tools, they are entirely usable by humans. In other words, you don't have to use a visual tool to use a bean.

Even though beans come in different flavors, these are the typical unifying features that distinguish a Java Bean (from the JavaBeans specification):

• 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 that can be used to connect up 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

Of course, not all software modules need to become beans; class libraries are appropriate in particular where the classes have no visual representation and are largely programmatic.