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

POJO(Plain Old Java Object) :- POJO are ordinary Java object, with no restrication other than those forced by the Java Language.

Serialization :- It is used to Save state of an object & send it across a network. It converts the state of an object into byte stream. We can recreate Java object from byte stream by process called Deserialization.

Make your class implement java.io.Serializable interface. And use writeObject() method of ObjectOutputStream class to achive Serialization.

JavaBean class :- It is a special POJO which have some restrication (or convention). 1. Implement Serialization 2. Have public no-arg constructor 3. All properties private with public getters & setter methods.

Many framework - like Spring - uses JavaBean object.

Answer 2

Properties of JavaBeans

A JavaBean is a Java object that satisfies certain programming conventions:

1. The JavaBean class must implement either Serializable or Externalizable

2. The JavaBean class must have a no-arg constructor

3. All JavaBean properties must have public setter and getter methods

4. All JavaBean instance variables should be private

Example of JavaBeans

@Entity
public class Employee implements Serializable{

   @Id
   private int id;
   private String name;   
   private int salary;  

   public Employee() {}

   public Employee(String name, int salary) {
      this.name = name;
      this.salary = salary;
   }
   public int getId() {
      return id;
   }
   public void setId( int id ) {
      this.id = id;
   }
   public String getName() {
      return name;
   }
   public void setName( String name ) {
      this.name = name;
   }
   public int getSalary() {
      return salary;
   }
   public void setSalary( int salary ) {
      this.salary = salary;
   }
}

Answer 3

A Java Bean is a component or the basic building block in the JavaBeans architecture. The JavaBeans architecture is a component architecture that benefits from reusability and interoperability of a component-based approach.

A valid component architecture should allow programs to be assembled from software building blocks (Beans in this case), perhaps provided by different vendors and also make it possible for an architect / developer to select a component (Bean), understand its capabilities, and incorporate it into an application.

Since classes/objects are the basic building blocks of an OOP language like Java, they are the natural contenders for being the Bean in JavaBeans architecture.

The process of converting a plain Java class to a Java bean is actually nothing more than making it a reusable and interoperable component. This would translate into a java class having abilities like :

1. controlling the properties, events, and methods of a class that are exposed to another application. (You can have a BeanInfo class that reports only those properties, events and methods that the external application needs)
2. persistence (being serialisable or externizable - this would also imply having no-argument constructors, using transient for fields)
3. ability to register for events and also to generate events (for e.g. making use of bound and constraint properties)
4. customizers (to customise the Bean via GUIs or by providing documentation)

In order for a Java class to be termed a Java bean it is not necessary that they need to possess all the above abilities, instead it implies to implement a subset of the above relevant to the context (for e.g. a bean in a certain framework may not need customizers, some other bean may not need bound and constrained properties etc)

Almost all leading frameworks and libraries in Java adhere to the JavaBeans architecture implicitly, in order to reap the above benefits.

Answer 4

To understand JavaBean you need to notice the followings: JavaBean is a conceptual stuff and can not represent a class of specific things

JavaBean is a development tool can be visualized in the operation of reusable software components

JavaBean is based on the Sun JavaBeans specification and can be reusable components. Its biggest feature is the re-usability.

Answer 5

A JavaBean is just a standard

1. All properties private (use getters/setters)
2. A public no-argument constructor
3. Implements Serializable.

That's it. It's just a convention. Lots of libraries depend on it though.

With respect to Serializable, from the API documentation:

Serializability of a class is enabled by the class implementing the java.io.Serializable interface. Classes that do not implement this interface will not have any of their state serialized or deserialized. All subtypes of a serializable class are themselves serializable. The serialization interface has no methods or fields and serves only to identify the semantics of being serializable.

In other words, serializable objects can be written to streams, and hence files, object databases, anything really.

Also, there is no syntactic difference between a JavaBean and another class -- a class is a JavaBean if it follows the standards.

There is a term for it because the standard allows libraries to programmatically do things with class instances you define in a predefined way. For example, if a library wants to stream any object you pass into it, it knows it can because your object is serializable (assuming the lib requires your objects be proper JavaBeans).

Answer 6

Just a little background/update on the bean concept. Many other answers actually have the what but not so much why of them.

They were invented early on in Java as part of building GUIs. They followed patterns that were easy for tools to pull apart letting them create a properties panel so you could edit the attributes of the Bean. In general, the Bean properties represented a control on the screen (Think x,y,width,height,text,..)

You can also think of it as a strongly typed data structure.

Over time these became useful for lots of tools that used the same type of access (For example, Hibernate to persist data structures to the database)

As the tools evolved, they moved more towards annotations and away from pulling apart the setter/getter names. Now most systems don't require beans, they can take any plain old java object with annotated properties to tell them how to manipulate them.

Now I see beans as annotated property balls--they are really only useful for the annotations they carry.

Beans themselves are not a healthy pattern. They destroy encapsulation by their nature since they expose all their properties to external manipulation and as they are used there is a tendency (by no means a requirement) to create code to manipulate the bean externally instead of creating code inside the bean (violates "don't ask an object for it's values, ask an object to do something for you"). Using annotated pojos with minimal getters and no setters is much more OO restoring encapsulation and with the possibility of immutability.

By the way, as all this stuff was happening someone extended the concept to something called Enterprise Java Beans. These are... different. and they are complicated enough that many people felt they didn't understand the entire Bean concept and stopped using the term. This is, I think, why you generally hear beans referred to as POJOs (since every java object is a POJO this is technically OK, but when you hear someone say POJO they are most often thinking about something that follows the bean pattern)