What is the difference between JavaBean and POJO?

POJO - Plain old Java Object - it is simply a denomination that is given to a "normal" object, without anything special. It has its fields, its methods, its constructors, etc, but it doesn't [necessarily] follow any pre-established patterns.

As the Java language has evolved, automated tools have emerged to interface with your code declaratively and / or visually, without the need to write code manually. Many sometimes these tools required-to perform their function-that the classes involved were written in a very specific way, otherwise they would not be compatible with these tools.

An example is the JavaBeans, which at the time I studied aimed to facilitate the creation of graphical user interfaces (I do not know how it is today, nor if this goal went ahead - since I have not worked with Java for years). A JavaBean needs, of the two a:

1. Follow a very strict convention, including a constructor without parameters and methods for obtaining and assigning values to your fields ("getters and setters") with a naming and signing pattern (i.e. number and types of parameters and return value);

2. Use a helper class-BeanDescriptor or something like that-to describe the class structure to tools that work with Beans, in case it was not possible to use the above convention. (why "kills" much of the advantages of working with beans)

Another format is EJB - Enterprise JavaBeans-in this case focused on a service-oriented architecture (SOA), if I'm not mistaken. And whenever a new tool emerged - for example, to do object-relational mapping-it was common to require a different, sometimes conflicting, pattern.

Faced with this multiplicity of patterns, and the problems that this entailed, we began to try make code-handling tools flexible enough to accept any format, regardless of pattern. In the absence of a proper name to describe this characteristic, the term POJO was coined, to express the idea that "for my tool to deal with your class does not need it to have anything special, a simple object any serves".

For this reason, say that any object is a POJO (for example, every JavaBean is a POJO, but not every POJO is a JavaBean) though technically correct doesn't mean much... On the other hand, saying that the X tool is about POJOs speaks volumes about the flexibility of this tool: because no matter what format your classes are in, it claims to be able to handle them. It is from this perspective that you should interpret the term "POJO", whenever you see it.