Are these synonymous, a subset of each other or completely different?

Are the notions mentionned in the question title synonymous to a 开发者_StackOverflowcertain degree? Where do the main differences lie (context, structure, ...) and can one be considered a subset of another? Here's some brief definitions taken from Wikipedia.

POJO (Plain Old Java Object) Wikipedia

In computing software, POJO is an acronym for Plain Old Java Object. The name is used to emphasize that a given object is an ordinary Java Object, not a special object, and in particular not an Enterprise JavaBean. The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000:

"We wondered why people were so against using regular objects in their
 systems and concluded that it was
 because simple objects lacked a fancy
 name. So we gave them one, and it's
 caught on very nicely."

Java Bean Wikipedia

JavaBeans are reusable software components for Java that can be manipulated visually in a builder tool. Practically, they are classes written in the Java programming language conforming to a particular convention. They are used to encapsulate many objects into a single object (the bean), so that they can be passed around as a single bean object instead of as multiple individual objects. A JavaBean is a Java Object that is serializable, has a nullary constructor, and allows access to properties using getter and setter methods.

Value Object Wikipedia

Data transfer object (DTO), formerly known as value objects or VO, is a design pattern used to transfer data between software application subsystems. DTOs are often used in conjunction with data access objects to retrieve data from a database.

Business Object Wikipedia

A business object is a type of an intelligible entity being an actor inside the business layer in a n-layered object-oriented computer program.

Related:

Difference between DTO, VO, POJO, JavaBeans? What is the difference between a JavaBean and a POJO? DDD: what's the use of the difference between entities and value objects?

Not all of these classifications are related. Here's my understanding:

• POJO is what its name suggests - a plain old Java object. There's nothing special about it. And this is exactly what we want to convey when we say that an object is a POJO. Today most applications are using some kinds of underlying frameworks, and with the frameworks come requirements on the objects that will integrate with the framework - the object must implement an interface or extend a class. When we say an object is a POJO, we mean to say it is just an ordinary object and has no dependencies on any framework.

• A JavaBean is a java class that follows certain conventions as described in your question. Such objects are often mandated by certain frameworks which use reflection to find out the properties (accessible through getters/setters) of the object and manipulate them e.g. beans exposed to JSPs, Spring beans etc. The good thing about JavaBeans is that they are still POJOs. Although they follow certain conventions, the conventions are not defined by any particular framework but are rather defined by Sun Javabean standard and the classes are still plain Java classes with no ties to any third party framework's classes or interfaces.

• Business Objects refer to objects that represent your business domain entities. These usually reside in your business layer - the layer where all the business logic is. These objects usually map to persistence store entities e.g. tables. These objects could be POJOs, JavaBeans, EJBs etc.

• Value objects are a type of design pattern. In some small web applications, you have the option of using your business objects in the web layer as well. However, in larger applications or J2EE applications, you define value objects to move information from the business layer to the web layer. That's why they are also called Data Transfer Objects (DTOs). These objects usually have only the attributes that are needed in the web layer and leave the attributes of business objects that were meant for business layer consumption behind. They may also have "computed" attributes that are generated in the business layer. Using this patterns helps decouple the business and web layers.

Here's my take:

1. Business objects is a generic term for the abstract idea that represents your problem. You can implement them in any language. In Java, you have additional choices to make, because they can be POJOs or EJBs, mutable or immutable.
2. Value objects or DTOs are used to ferry data between layers. They're usually immutable. They can be implemented as POJOs or Java Beans. Think of them as another subset of POJOs.
3. A Java Bean conforms to the original Sun specification. They were intended to provide an interface that would allow them to be plugged into a VB-style IDE with ease. Think of these as a subset of POJO.
4. People sometimes get confused about the difference between Java Beans and Enterprise Java Beans. Java Beans are part of the original Java 1.0 spec, intended to be like VB components (remember "Bean Box"?). Enterprise Java Beans were a spec that followed that described how special Java objects would implement specific interfaces to interoperate with a Java EE app server. The app server was a transaction monitor for a distributed component architecture that would handle threading, persistence, pooling, object lifecycle, messaging, naming, etc. EJBs are a very special subset of Java objects that work only within the context of a Java EE app server.
5. A POJO can be implemented to conform to the Java Bean standard, but it's not a requirement. Any Java object qualifies as a POJO. It was originally meant to distinguish them from EJB version 2.0, which required several interfaces in order to interoperate with the Java EE app server properly.

The questions is whether it's a mistake to use some of these as synonyms (like I've heard some people do) and if a given classification can be considered as a subset or another.

It is a mistake to use these terms as synonyms. They clearly have distinct meanings. The quoted definitions (and those provided in other answers) make this clear.

However, if it is often valid to use many (or even all) of these terms to describe the same object or objects. It is all a matter of perspective; i.e. what aspect of the object(s) you are trying to emphasize.

Synthesis (from answers given):

• POJO: An ordinary object with no dependencies towards any framework. It can be adapted to conform to the Java Bean standard without being a requirement as such.
• JavaBean: Object conforming to the Sun JavaBean or Java 1.0 specification (refer to "Bean box"). They were originally intended to provide an interface so they could be plugged into a VB-style IDE with little difficulty. Can be considered as a subset of POJOs and remain independant of frameworks. It can employ certain mecanisms such as reflection to access properties.
• Enterprise Java Bean: These shouldn't be confused with Java Beans. With the simplifications brought about with version 3.0, EJBs can be considered as equivalent to a POJO. EJB in itself is a specification describing special Java Objects that can interoperate with a Java EE server. The server as such acted as a transaction monitor in the context of a distributed component architecture handling things such as threading, persistence, pooling, object lifecycle, messaging and naming. As such an EJB can be viewed as a very special subset that used in the contect of a Java EE application server.
• Business object: Theoretical concept or abstract idea that helps to represent a given problem. It represents business domain entities and resides in the business layer of an application. They can be mapped to entities in the context of persistance. The object can be a POJO/JavaBean/EJB and be either mutable or immutable.
• Value object/Data Transfer Object: Employs a design pattern which helps to decouple the business and web layers. This is to suit the context of large applications where objects can transit between layers (the business and web layer for example). They're usually immutable in nature and can either be formated as POJOs or Java Beans. One specificity is that they can contain computed attributes that are generated in the business layer.

P.S: Marked as community wiki so feel free to edit.