dependency-injection inversion-of-control java javabeans serializable

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 JavaBean and a regular class?
Is there any special definition or an Interface?

Basically, why is there a term for this?

Also what does the Serializable interface mean?


  • 21

    See places where Java Beans used?. It’s a class following certain conventions.

    Jul 21, 2010 at 0:52

  • 10

    For the sake of completeness, here is a link to the JavaBeans Specification.

    Jan 20, 2014 at 4:47

  • 5

    Just a note. If you ever hear people throw around the term POJO, they often actually mean Bean. When you see POJOs they nearly always have setters & getters, are serializable, … In actuality a POJO does not require setters and getters, a serializable interface or anything else–it is simply a Plain Old Java Object with no specific requirements.

    – Bill K

    Apr 12, 2019 at 17:07

  • 1

    Definitely not a struct, but I’m glad you asked the question.

    Feb 17, 2021 at 19:31


A JavaBean is just a standard. It is a regular Java class, except it follows certain conventions:

  1. All properties are 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 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 library requires your objects be proper JavaBeans).


  • 285

    Right on, in my opinion almost all documentation revolving around beans can’t describe the term as concisely as you have. +1

    – AndaP

    Sep 20, 2012 at 12:42

  • 16

    Is it required for the members of a bean to also be beans? Seems like a reasonable requirement..

    May 6, 2013 at 8:01

  • 24

    @worldsayshi – No, it’s not required. For example a bean can contain a String; and String is not a bean. (String is immutable, so you cannot create it by calling an empty constructor and a setter.) It seems reasonable that a Serializable object should have Serializable members, unless it somehow serializes them from outside. So no, Java bean members do not need to have any aspect of Java beans. Although it is more simple if they are beans, too.

    Aug 2, 2013 at 5:46

  • 16

    “All properties private” is not correct. Properties are inferred from the getters and setters (if there is a method X getFoo() -> the bean has a readable property called “foo”; if there is a method setFoo(X foo) -> the bean has a writeable property called “foo”). Properties can be backed by member fields (but don’t have to be) which are usually private.

    – Puce

    Dec 1, 2015 at 16:19

  • 3

    I hope for being a Java bean “a class must be Public”. And is it really need that it should implement Serializable Interface??

    May 27, 2016 at 7:12


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, 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 zero-argument 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 information 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.)


  • 1

    This is probably a stupid question but, what could an instance field be besides a primitive type or an instance of a class?

    Nov 29, 2016 at 15:35

  • 9

    @kingfrito_5005: It’s going to be one or the other. But if it’s an instance of a class, it matters whether that class is serializable or not. In order for a class to be serializable, its non-transient parts have to be of some serializable type.

    – cHao

    Nov 29, 2016 at 16:21

  • probably forgot to mention that the constructor should have no arguments . has a public default constructor (so it can be created at will and configured by setting its properties).

    Oct 5, 2018 at 9:46

  • @AmosKosgei: Didn’t forget; it’d just be redundant. A default constructor by definition can be called with no arguments.

    – cHao

    Oct 5, 2018 at 12:35

  • 3

    @Amos: As i look into it, though, it seems “default constructor” means something slightly different in Java from in C++. 😛 Replaced “default” with “0-arg”.

    – cHao

    Oct 5, 2018 at 12:58


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

  1. implement the interface – to save the state of an
  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).