Tutorial :What is a JavaBean exactly?


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?

Also, is there a real syntactic difference between a bean and a regular class? Is there any special definition or an interface?

Basically, why is there a term for this?

Edit: If you can be so kind and add information regarding the Serializable interface, and what it means.

To your answer, I'd be very grateful.


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).


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).


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.)


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 ).


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;     }  }  


Java Beans are using for less code and more work approach... Java Beans are used throughout Java EE as a universal contract for runtime discovery and access. For example, JavaServer Pages (JSP) uses Java Beans as data transfer objects between pages or between servlets and JSPs. Java EE's JavaBeans Activation Framework uses Java Beans for integrating support for MIME data types into Java EE. The Java EE Management API uses JavaBeans as the foundation for the instrumentation of resources to be managed in a Java EE environment.

About Serialization:

In object serialization an object can be represented as a sequence of bytes that includes the object's data as well as information about the object's type and the types of data stored in the object.

After a serialized object has been written into a file, it can be read from the file and deserialized that is, the type information and bytes that represent the object and its data can be used to recreate the object in memory.


Explanation with an example.

1. import java.io.Serializable

As for the Serialization, see the documentation.

2. private fields

Fields should be private for prevent outer classes to easily modify those fields. Instead of directly accesing to those fields, usuagly getter/setter methods are used.

3. Constructor

A public constructor without any argument.

4. getter/setter

Getter and setter methods for accessing and modifying private fields.

/** 1. import java.io.Serializable */  public class User implements java.io.Serializable {      /** 2. private fields */      private int id;      private String name;        /** 3. Constructor */      public User() {      }      public User(int id, String name) {          this.id = id;          this.name = name;      }        /** 4. getter/setter */      // getter      public int getId() {          return id;      }      public String getName() {          return name;      }      // setter      public void setId(int id) {          this.id = is;      }      public void setName(String name) {          this.name = name;      }  }  


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


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.


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.


Regarding the second part of your question, Serialization is a persistence mechanism used to store objects as a sequence of signed bytes. Put less formally, it stores the state of an object so you can retrieve it later, by de-serialization.


A Java Bean is a java class [conceptual] that should follow following conventions:

  1. It should have a no-arg constructor.
  2. It should be Serializable.
  3. It should provide methods to set and get the values of the properties, known as getter and setter methods.

It is a reusable software component. It can encapsulate many object into one object so that same object can be accessed from multiples places and is a step towards easy maintenance of code.


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.according to wiki

The objects that form the backbone of your application and that are managed by the Spring IoC container are called beans. A bean is an object that is instantiated, assembled, and otherwise managed by a Spring IoC container. Otherwise, a bean is simply one of many objects in your application. according to spring io.


A Java Bean is essentially a class, what classifies a class as a bean is:

  1. It should implement serializable interface (A Marker interface).
  2. The constructor should be public and have no arguments (What other people call it a no-arg constructor).
  3. It should have getter and setters.

Good to note the serialVersionUID field is important for maintaining object state. Below code qualifies as a bean:

public class DataDog implements java.io.Serializable {    private static final long serialVersionUID = -3774654564564563L;    private int id;  private String nameOfDog;    //The constructor should NOT have arguments  public DataDog () {}      /** 4. getter/setter */    // getter(s)  public int getId() {      return id;  }  public String getNameOfDog() {      return nameOfDog;  }  // setter(s)  public void setId(int id) {      this.id = id;  }  public void setNameOfDog(String nameOfDog) {      this.nameOfDog = nameOfDog;  }}  


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.


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)

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »