JavaBeans

In computing based on the Java Platform, JavaBeans are classes that encapsulate many objects into a single object (the bean). They are serializable, have a zero-argument constructor, and allow access to properties using getter and setter methods. The name "Bean" was given to encompass this standard, which aims to create reusable software components for Java.

It is a reusable software component written in Java that can be manipulated visually in an application builder tool.

Features

Introspection
Introspection is a process of analyzing a Bean to determine its capabilities. This is an essential feature of the Java Beans API because it allows another application such as a design tool, to obtain information about a component.
Properties
A property is a subset of a Bean's state. The values assigned to the properties determine the behaviour and appearance of that component. They are set through a setter method and can be obtained by a getter method.
Customization
A customizer can provide a step-by-step guide that the process must follow to use the component in a specific context.
Events
Beans may interact with the EventObject EventListener model.
Persistence
Persistence is the ability to save the current state of a Bean, including the values of a Bean's properties and instance variables, to nonvolatile storage and to retrieve them at a later time.
Methods
A bean should use accessor methods to encapsulate the properties. A bean can provide other methods for business logic not related to the access to the properties.

Advantages

  • The properties, events, and methods of a bean can be exposed to another application.
  • A bean may register to receive events from other objects and can generate events that are sent to those other objects.
  • Auxiliary software can be provided to help configure a bean.
  • The configuration settings of a bean can be saved to persistent storage and restored.

Disadvantages

  • A class with a zero-argument constructor is subject to being instantiated in an invalid state.[1] If such a class is instantiated manually by a developer (rather than automatically by some kind of framework), the developer might not realize that the class has been improperly instantiated. The compiler cannot detect such a problem, and even if it is documented, there is no guarantee that the developer will see the documentation.
  • JavaBeans are inherently mutable and so lack the advantages offered by immutable objects.[1]
  • Having to create getters for every property and setters for many, most, or all of them can lead to an immense quantity of boilerplate code. This can be mitigated using tools like Lombok.

JavaBeans API

The JavaBeans functionality is provided by a set of classes and interfaces in the java.beans package.

InterfaceDescription
AppletInitializerMethods in this interface are used to initialize Beans that are also applets.
BeanInfoThis interface allows the designer to specify information about the events, methods and properties of a Bean.
CustomizerThis interface allows the designer to provide a graphical user interface through which a bean may be configured.
DesignModeMethods in this interface determine if a bean is executing in design mode.
ExceptionListenerA method in this interface is invoked when an exception has occurred.
PropertyChangeListenerA method in this interface is invoked when a bound property is changed.
PropertyEditorObjects that implement this interface allow the designer to change and display property values.
VetoableChangeListenerA method in this interface is invoked when a Constrained property is changed.
VisibilityMethods in this interface allow a bean to execute in environments where the GUI is not available.

JavaBean conventions

In order to function as a JavaBean class, an object class must obey certain conventions about method naming, construction, and behaviour. These conventions make it possible to have tools that can use, reuse, replace, and connect Java Beans.

The required conventions are as follows:

  • The class must have a public default constructor (with no arguments). This allows easy instantiation within editing and activation frameworks.
  • The class properties must be accessible using get, set, is (can be used for boolean properties instead of get), to and other methods (so-called accessor methods and mutator methods) according to a standard naming convention. This allows easy automated inspection and updating of bean state within frameworks, many of which include custom editors for various types of properties. Setters can have one or more than one argument.
  • The class should be serializable. (This allows applications and frameworks to reliably save, store, and restore the bean's state in a manner independent of the VM and of the platform.)

Code example

package player;

public class PersonBean implements java.io.Serializable {

    /** Properties **/
    private boolean deceased = false;

    private List list;

    /** Property "name", readable/writable. */
    private String name = null;

    /** No-arg constructor (takes no arguments). */
    public PersonBean() {
    }

    public List getList() {
        return list;
    }
	
    public void setList(final List list) {
        this.list = list;
    }

    /**
     * Getter for property "name".
     */
    public String getName() {
        return name;
    }

    /**
     * Setter for property "name".
     *
     * @param value
     */
    public void setName(final String value) {
        this.name = value;
    }

    /**
     * Getter for property "deceased"
     * Different syntax for a boolean field (is v.s. get)
     */
    public boolean isDeceased() {
        return deceased;
    }

    /**
     * Setter for property "deceased".
     * @param value
     */
    public void setDeceased(boolean value) {
        deceased = value;
    }
}

TestPersonBean.java:

import player.PersonBean;

/**
 * Class "TestPersonBean".
 */
public class TestPersonBean {
    /**
     * Tester method "main" for class "PersonBean".
     *
     * @param arguments
     */
    public static void main(final String[] arguments) {
        final PersonBean person = new PersonBean();

        person.setName("Bob");
        person.setDeceased(false);
        person.setList(new ArrayList());

        // Output: "Bob [alive]"
        System.out.print(person.getName());
        System.out.println(person.isDeceased() ? " [deceased]" : " [alive]");
    }
}
<jsp:useBean id="person" class="player.PersonBean" scope="page"/>
<jsp:setProperty name="person" property="*"/>

<html>
    <body>
        Name: <jsp:getProperty name="person" property="name"/><br/>
        Deceased? <jsp:getProperty name="person" property="deceased"/><br/>
        <br/>
        <form name="beanTest" method="POST" action="testPersonBean.jsp">
            Enter a name: <input type="text" name="name" size="50"><br/>
            Choose an option:
            <select name="deceased">
                <option value="false">Alive</option>
                <option value="true">Dead</option>
            </select>
            <input type="submit" value="Test the Bean">
        </form>
    </body>
</html>
gollark: This violates "if it compiles, it runs".
gollark: This is totally definitely* a joke.
gollark: It's clearly 50MB.
gollark: It doesn't SEEM 50GB.
gollark: No. It WILL be dynamically allocate.

References

  1. Bloch, Joshua (2008). Effective Java (Second ed.). Addison-Wesley. p. 13. ISBN 978-0-321-35668-0.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.