What is a JavaBean exactly?

Question

I understood, I think, that a \"Bean\" is a Java class with properties and getters/setters. As much as I understand, it is the equivalent of a C struct. Is that true?

<

Answer 1

Java Beans is a standard, and its basic syntax requirements have been clearly explained by the other answers.

However, IMO, it is more than a simple syntax standard. The real meaning or intended usage of Java Beans is, together with various tool supports around the standard, to facilitate code reuse and component-based software engineering, i.e. enable developers to build applications by assembling existing components (classes) and without having to write any code (or only have to write a little glue code). Unfortunately this technology is way under-estimated and under-utilized by the industry, which can be told from the answers in this thread.

If you read Oracle's tutorial on Java Beans, you can get a better understanding in that.

Answer 2

There's a term for it to make it sound special. The reality is nowhere near so mysterious.

Basically, a "Bean":

• is a serializable object (that is, it implements java.io.Serializable, and does so correctly), that
• has "properties" whose getters and setters are just methods with certain names (like, say, getFoo() is the getter for the "Foo" property), and
• has a public 0-arg constructor (so it can be created at will and configured by setting its properties).

Update:

As for Serializable: That is nothing but a "marker interface" (an interface that doesn't declare any functions) that tells Java that the implementing class consents to (and implies that it is capable of) "serialization" -- a process that converts an instance into a stream of bytes. Those bytes can be stored in files, sent over a network connection, etc, and have enough info to allow a JVM (at least, one that knows about the object's type) to reconstruct the object later -- possibly in a different instance of the application, or even on a whole other machine!

Of course, in order to do that, the class has to abide by certain limitations. Chief among them is that all instance fields must be either primitive types (int, bool, etc), instances of some class that is also serializable, or marked as transient so that Java won't try to include them. (This of course means that transient fields will not survive the trip over a stream. A class that has transient fields should be prepared to reinitialize them if necessary.)

A class that can not abide by those limitations should not implement Serializable (and, IIRC, the Java compiler won't even let it do so.)

Answer 3

JavaBeans are Java classes which adhere to an extremely simple coding convention. All you have to do is to

1. implement java.io.Serializable interface - to save the state of an object
2. use a public empty argument constructor - to instantiate the object
3. provide public getter/setter methods - to get and set the values of private variables (properties ).

Answer 4

You will find Serialization useful when deploying your project across multiple servers since beans will be persisted and transferred across them.

Answer 5

As per the Wikipedia:

1. The class must have a public default constructor (with no arguments). This allows easy instantiation within editing and activation frameworks.

2. The class properties must be accessible using get, set, is (can be used for boolean properties instead of get), 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.

3. 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.]

For more information follow this link.

Answer 6

A bean is a Java class with method names that follow the Java Bean guidelines (also called design patterns) for properties, methods, and events . Thus, any public method of the bean class that is not part of a property definition is a bean method. Minimally, a Java class even with either a property as the sole member (of course, accompanying public getter and setter required), a public method as the sole member or just one public event listener registration method is a Java bean. Furthermore, the property can either be read-only property (has a getter method but no setter) or write-only property (has a setter method only). The Java bean needs to be a public class to be visible to any beanbox tool or container. The container must be able to instantiate it; thus, it must have a public constructor too. The JavaBeans specification doesn’t require a bean to have a public zero-args constructor, explicit or default, for a container to instantiate it. If you could provide a file (with extension .ser) containing a serialized instance, a beanbox tool could use that file to instantiate a prototype bean. Otherwise, the bean must have a public zero-args constructor, either explicit or default.

Once the bean is instantiated, the Java Bean API ( java.beans.*) can introspect it and call methods on it. If no class implementing the interface BeanInfo or extending a BeanInfo implementation , SimpleBeanInfo class, is available, the introspection involves using reflection (implicit introspection) to study the methods supported by a target bean and then apply simple design patterns(the guidelines) to deduce from those methods what properties, events, and public methods are supported. If a class implementing the interface BeanInfo (for a bean Foo, it must be named FooBeanInfo) is available, the API bypasses implicit introspection and uses public methods (getPropertyDescriptor(), getMethodDescriptors(), getEventSetDescriptors() ) of this class to get the information. If a class extending SimpleBeanInfo is available, depending on which of the SimpleBeanInfo public methods (getPropertyDescriptor(), getMethodDescriptors(), getEventSetDescriptors() ) are overridden, it will use those overridden methods(s) to get information; for a method that is not overridden, it’ll default to the corresponding implicit introspection. A bean needs to be instantiated anyway even if no implicit introspection is carried on it. Thus, the requirement of a public zeri-args constructor. But, of course, the Serializable or Externalizable interface isn’t necessary for it to be recognized. However the Java Bean specification says, ‘We’d also like it to be “trivial” for the common case of a tiny Bean that simply wants to have its internal state saved and doesn’t want to think about it.’ So, all beans must implement Serializable or Externalizable interface. Overall, JavaBeans specification isn’t hard and fast about what constitutes a bean. "Writing JavaBeans components is surprisingly easy. You don't need a special tool and you don't have to implement any interfaces. Writing beans is simply a matter of following certain coding conventions. All you have to do is make your class look like a bean — tools that use beans will be able to recognize and use your bean." Trivially, even the following class is a Java Bean,

public class Trivial implements java.io.Serializable {}

Say, a bean constructor has some parameters. Suppose some are simple types. The container might not know what values to assign to them; even if it does, the resulting instance might not be reusable. It may make sense only if the user can configure (specify values) by say annotations or xml configuration files as in Spring beans. And suppose some parameters are class or interface types. Again, the container might not know what values to assign to it. It may make sense only if the user can configure (specify specific objects) by say annotations or xml configuration files. However, even in Spring (via xml configuration files), assigning specific objects (with string names) to constructor arguments ( attribute or element of constructor arguments)is not typesafe;it is basically like resource injection. Making references to other Spring beans(called collaborators; via element in a constructor argument element) is basically dependency injection and thus typesafe. Obviously, a dependency(collaborator bean) might have a constructor with injected parameters; those injected dependency(ies) might have a constructor with parameters and so on. In this scenario, ultimately, you would need some bean classes (e.g, MyBean.class) that the container can instantiate by simply calling new MyBean() before it can construct the other collaborating beans via dependency injection on constructors—thus, the requirement for the beans to have public zero-args constructor. Suppose, if a container doesn’t support dependency injection and/or doesn’t allow assigning simple-type values to constructor via some annotations or xml config files as in Spring, bean constructors shouldn’t have parameters. Even a Spring beans application would need some beans to have public zero-args constructor (e.g., in a scenario where your Spring application has no bean with just simple types as constructor arguments).

JSF managed beans run in a web container. They can be configured either with @ManagedBean annotation or with an application configuration resource file managed-bean.xml. However, it supports injection via resource injection (not typesafe) only; not fit for injection on constructors. The JSF spec requires that managed beans must have a public zero-argument constructors . Further it says, “As of version 2.3 of this specification, use of the managed bean facility as specified in this section is strongly discouraged. A better and more cohesively integrated solution for solving the same problem is to use Contexts and Dependency Injection (CDI), as specified in JSR-365." In other words, CDI managed beans to be used, which offers typesafe dependency injection on constructors akin to Spring beans. The CDI specification adopts the Managed Beans specification, which applies to all containers of the JEE platform, not just web tier. Thus, the web container needs to implement CDI specification.

Here is an extract from the Managed Bean specification “ Managed Beans are container-managed objects with minimal requirements, otherwise known under the acronym “POJOs” (Plain Old Java Objects)…they can be seen as a Java EE platform-enhanced version of the JavaBeans component model found on the Java SE platform…. It won’t be missed by the reader that Managed Beans have a precursor in the homonymous facility found in the JavaServer Faces (JSF) technology…Managed Beans as defined in this specification represent a generalization of those found in JSF; in particular, Managed Beans can be used anywhere in a Java EE application, not just in web modules. For example, in the basic component model, Managed Beans must provide a no-argument constructor, but a specification that builds on Managed Beans, such as CDI (JSR-299), can relax that requirement and allow Managed Beans to provide constructors with more complex signatures, as long as they follow some well-defined rules...A Managed Bean must not be: a final class, an abstract class, a non-static inner class. A Managed Bean may not be serializable unlike a regular JavaBean component.” Thus, the specification for Managed Beans, otherwise known as POJOs or POJO beans, allows extension as in CDI.

The CDI specification re-defines managed beans as: When running in Java EE, A top-level Java class is a managed bean if it meets requirements:

• It is not an inner class. • It is a non-abstract class, or is annotated @Decorator. • It does not implement javax.enterprise.inject.spi.Extension. • It is not annotated @Vetoed or in a package annotated @Vetoed. • It has an appropriate constructor, either: the class has a constructor with no parameters, or the class declares a constructor annotated @Inject.

All Java classes that meet these conditions are managed beans and thus no special declaration is required to define a managed bean. Or

if it is defined to be a managed bean by any other Java EE specification and if

• It is not annotated with an EJB component-defining annotation or declared as an EJB bean class in ejb-jar.xml.

Unlike Spring beans it doesn’t support constructors with simple-types, which might be possible if it supported configuration with xml config files like in Spring or any annotations.

EJBs run in an EJB container. Its specification says: “A session bean component is a Managed Bean." “The class must have a public constructor that takes no arguments,” it says for both session bean and message-driven bean. Further, it says, “The session bean class is not required to implement the SessionBean interface or the Serializable interface.” For the same reason as JSF beans, that EJB3 dependency injection is basically resource injection, JSF beans do not support constructors with arguments, that is, via dependency injection. However, if the EJB container implements CDI, “ Optionally: The class may have an additional constructor annotated with the Inject annotation, “ it says for both session bean and message-driven bean because, “An EJB packaged into a CDI bean archive and not annotated with javax.enterprise.inject.Vetoed annotation, is considered a CDI-enabled bean.”