Plain Old Java Objects

In software engineering, a plain old Java object (POJO) is an ordinary Java object, not bound by any special restriction. The term was coined by Martin Fowler, Rebecca Parsons and Josh MacKenzie in September 2000:

The term "POJO" initially denoted a Java object which does not follow any of the major Java object models, conventions, or frameworks. It has since gained adoption as a language-agnostic term, because of the need for a common and easily understood term that contrasts with complicated object frameworks.

The term continues an acronym pattern to coin retronyms for constructs that do not use fancy new features:

* "Plain old JavaScript object" in JavaScript
* "Plain old Ruby object" (PORO) in Ruby
* "Plain old Documentation" (pod) in Perl
* Plain old CLR object (POCO) in the .NET Framework
* "Plain old PHP object" (POPO) in PHP
* Plain old telephone service (POTS) in telephony

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
#Extend prespecified classes, as inpublic class Foo extends javax.servlet.http.HttpServlet { ...
#Implement prespecified interfaces, as inpublic class Bar implements javax.ejb.EntityBean { ...
#Contain prespecified annotations, as [e-mail] 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.
The idea is that if the object (actually class) were a POJO before any annotations were added, and would return to POJO status if the annotations are removed then it can still be considered a POJO. Then the basic object remains a POJO in that it has no special characteristics (such as an implemented interface) that makes it a "Specialized Java Object" (SJO or (sic) SoJO).

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 JavaBeans specification, if fully implemented, slightly breaks the POJO model as the class must implement the Serializable interface to be a true JavaBean. Many POJO classes still called JavaBeans do not meet this requirement. Since Serializable is a marker (method-less) interface, this is not much of a burden.

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

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()" (or "isSomeProperty()" if the property is of Boolean type) method for getting a value, and to the "setSomeProperty(String)" method for setting a value.

Th
lombok
library allows to change the code dynamically to integrate those conventions without the hassle to write them. The following code would generate the same bean, with the addition of an empty constructor :@NoArgsConstructor
public class MyBean {

@Getter @Setter
private String someProperty;

}Other libraries or framework generate code (or bytecode) with those conventions directly. The addition of those tools help alleviate the boilerplate, which in turn reduces the bugs frequency and maintenance cost .

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 focuses on business logic and has no dependencies on (enterprise) frameworks. Aspect-oriented programming (AOP) frameworks then transparently add cross-cutting concerns like persistence, transactions, security, and so on.Martin, Robert C; (2008); ''Clean Code'', Chapter 11, ''Pure Java AOP Frameworks''

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

An example of an EJB bean being a POJO:

* Enterprise JavaBeans (EJB),
* Java Persistence API (JPA) (including Hibernate)

CDI (Contexts and Dependency Injection for the Java EE platform)

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:

helloWorld
com.example.HelloWorldService
stateless

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.Panda, Debu; Rahman, Reza; Lane, Derek; (2007). ''EJB 3 in action'', Manning Publications Co., Shelter Island (NY), (www.manning.com/books/ejb-3-in-action). Chapter 11, ''Deployment descriptors vs. annotations''

Thus, as an alternative to XML, many frameworks (e.g. Spring, EJB and JPA) allow annotations to be used instead of or in addition to XML. The following shows the same EJB bean as shown above but with an annotation added. In this case the XML file is no longer needed:

@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. Accordingly, the programming model is still very much like the pure POJO model.

Related Acronyms

Plain old Java Interface

A Plain old Java Interface (POJI) is a basic form of Java interface and acceptable at points where more complex Java interfaces are not permitted.

See also

* Data transfer object (DTO)
* Anemic domain model
* KISS principle

References

{{Reflist, refs=

{{cite book, title=Rational Application Developer V7.5 Programming Guide, first1=Ueli, last1=Wahli, first2=Miguel, last2=Vieira, first3=Ferreira Lopes, last3=Gomes, first4=Brian, last4=Hainey, first5=Ahmed, last5=Moharram, first6=JuanPablo, last6=Napoli, first7=Marco, last7=Rohr, first8=Henry, last8=Cui, first9=Patrick, last9=Gan, first10=Celso, last10=Gonzalez, first11=Pinar, last11=Ugurlu, first12=Lara, last12=Ziosi, date=29 June 2009, publisher=IBM Redbooks, isbn=978-0738432892

Java (programming language)
Computer jargon