Beans are everywhere, popping up in web-application frameworks, enterprise applications, Swing Graphical User Interface (GUIs), templating engines, and object-relational mapping (ORM) tools. Most systems have some sort of object model; for example, an electronic commerce application would have an object model involving an Invoice, which relates to a Customer; or a sports news web site would have related Athlete, Sport, and Team objects. Frequently, objects in these object models are beans—simple objects with properties, encapsulating access to these properties via public getter and setter methods.

In 1997, Sun Microsystems published Version 1.01 of the JavaBeans© specification. Initially, Sun offered beans as visual components for graphical user interfaces; JavaBeans were to be the equivalent of Microsoft’s ActiveX controls—a framework and set of interfaces for creating reusable and pluggable GUI components. Used as components, which exposed states through a series of accessor and mutator (getX( ) and setX()) methods, a developer would develop a GUI Java application by creating a visual layout using an IDE like Visual Cafe or JBuilder. If you’ve ever developed with Microsoft tools, you’ll know exactly what this means—Java was going to unseat Visual Basic, and GUI development was going to be easier than easy. According to the JavaBeans Specification Version 1.01 from 1997:

Don’t be misled; 1997 was ages ago, and the concept of the bean has evolved. In the last seven years, Java has become a dominant technology for server-side applications; impressive Swing applications do exist, but Java has not been an attractive platform for desktop application development due to reasons technical, economic, and judicial.

Don’t be confused by the 1997 JavaBeans specification, either; it is still relevant, but, when used in the context of this book, the term bean is any object with a no-argument constructor, which encapsulates access to private member variables via getter and setter methods. Example 3-1 defines a bean, SimpleBean , which contains two bean properties—name1 and name2.

package org.test.bean;

public class SimpleBean {
    private String name1;
    private String name2;

    public SimpleBean( ) {}

    public String getName1( ) { return name1; }
    public void setName1(String name1) { this.name1 = name1; }

    public String getName2( ) { return name2; }
    public void setName2(String name2) { this.name2 = name2; }
}

The presence of the public methods getName1( ) and getName2( ) make the bean properties name1 and name2 readable, and the public methods setName1( ) and setName2( ) make these properties writable. A bean should also have a public no-argument constructor; other constructors are not prohibited, but, since many tools need to dynamically create and populate beans, a no-argument constructor is required.

The original JavaBeans specification is available at http://java.sun.com/products/javabeans/docs/spec.html. The JavaBeans specification still exists and features have been added to the Java 1.4 release to support reading and writing JavaBeans to Extensible Markup Language (XML) documents. More information about more modern additions to the JavaBeans specification can be found at http://java.sun.com/j2se/1.4.2/docs/guide/beans/changes14.html.