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. 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."^[1]

The term "POJO Bína" is mainly used to denote a Java object which does not follow any of the major Java object models, conventions, or frameworks. The term continues the pattern of older terms for technologies that do not use fancy new features, such as POTS (Plain Old Telephone Service) in telephony, and PODS (Plain Old Data Structures) that are defined in C++ but use only C language features, and POD (Plain Old Documentation) in Perl. The equivalent to POJO on the .NET framework is Plain Old CLR Object.

The POJO phenomenon has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated object frameworks.

Definition

Ideally speaking, a POJO is a Java object not bound by any restriction other than those forced by the Java Language Specification. I.e., a POJO should not have to

1. Extend prespecified classes, as in

   public class Foo extends javax.servlet.http.HttpServlet { ...
   

2. Implement prespecified interfaces, as in

   public class Bar implements javax.ejb.EntityBean { ...
   

3. Contain prespecified annotations, as in

   @javax.persistence.Entity public class Baz { ...
   

However, due to technical difficulties and other reasons, many software products or frameworks described as POJO-compliant actually still require the use of prespecified annotations for features such as persistence to work properly.

Contextual variations

JavaBeans

A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods that follow a simple naming convention. Because of this convention, simple declarative references can be made to the properties of arbitrary JavaBeans. Code using such a declarative reference does not have to know anything about the type of the bean, and the bean can be used with many frameworks without these frameworks having to know the exact type of the bean.

The following shows an example of a JSF component having a bidirectional binding to a POJO's property:

<h:inputText value="#{myBean.someProperty}"/>

The definition of the POJO can be as follows:

public class MyBean {
 
    private String someProperty;
 
    public String getSomeProperty() {
         return someProperty;
    }
 
    public void setSomeProperty(String someProperty) {
        this.someProperty = someProperty;
    }
}

Because of the JavaBean naming conventions the single "someProperty" reference can be automatically translated to the "getSomeProperty()" method for getting a value, and to the "setSomeProperty(String)" method for setting a value.

Transparently adding services

As designs using POJOs have become more commonly used, systems have arisen that give POJOs the full functionality used in frameworks and more choice about which areas of functionality are actually needed. In this model, the programmer creates nothing more than a POJO. This POJO purely focusses on business logic and has no dependencies on (enterprise) frameworks. AOP frameworks then transparently add cross-cutting concerns like persistence, transactions, security, and so on.^[2]

Spring was an early implementation of this idea and one of the driving forces behind popularizing this model.

Other examples are:

• Enterprise JavaBeans,
• JPA (including Hibernate)
• CDI

The following shows a fully functional EJB bean, demonstrating how EJB3 leverages the POJO model:

public class HelloWorldService {
 
    public String sayHello() {
        return "Hello, world!";
    }
}

As given, the bean does not need to extend any EJB class or implement any EJB interface and also does not need to contain any EJB annotations. Instead, the programmer declares in an external xml file which EJB services should be added to the bean:

<enterprise-beans>
    <session>
        <ejb-name>helloWorld</ejb-name>
        <ejb-class>com.example.HelloWorldService</ejb-class>
       <session-type>stateless</session-type>
    </session>
</enterprise-beans>

In practice, some people find annotations elegant, while they see XML as verbose, ugly and hard to maintain, yet others find annotations pollute the POJO model. ^[3]

Thus, as an alternative to XML, many frameworks (e.g. Spring, EJB and JPA) allow annotations to be used instead or in addition to XML:

@Stateless
public class HelloWorldService {
 
    public String sayHello() {
        return "Hello, world!";
    }
}

With the annotation as given above the bean isn't a truly pure POJO anymore, but since annotations are merely passive metadata this has far fewer harmful drawbacks compared to the invasiveness of having to extend classes and/or implement interfaces.^[4] Accordingly, the programming model is still very much like the pure POJO model.

See also

• Data Transfer Object
• Anemic Domain Model

References