Plain Old Java Object

From Wikipedia, the free encyclopedia

POJO is an acronym for Plain Old Java Object, and is favoured by advocates of the idea that the simpler the design, the better. The name is used to emphasize that the object in question is an ordinary Java Object, not a special object, and in particular not an Enterprise JavaBean (especially before EJB 3). 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 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.

The term has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated object frameworks. A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods. An Enterprise JavaBean is not a single class but an entire component model (again, EJB 3 reduces the complexity of Enterprise JavaBeans).

As designs using POJOs have become more commonly-used, systems have arisen that give POJOs some of the functionality used in frameworks and more choice about which areas of functionality are actually needed. Hibernate and Spring are examples.

The equivalent to POJO on the .NET framework is Plain Old CLR Object.

[edit] Contextual variations

As of November 2005, the term "POJO" is mainly used to denote a Java object which does not follow any of the (major) Java object models, conventions, or frameworks such as EJB.

All Java objects are POJOs, therefore 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.ejb.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.

[edit] POJO generation projects

OpenXava 
Framework to develop J2EE business applications rapidly and easily. It's based in business components defined with XML. Feature rich and flexible since it's used for years to create business applications. Generates POJO Hibernate EJB2 and EJB3 JPA ...
PlainXML 
Generating POJO by DTD; XML-POJO mapping via Java5 annotations or DTD; XML manipulations using POJO without SAX/DOM; Preprocessing of XML documents using expression language; Binary XML; RMI friendly XML; Exporting to JSON; XML marshall/unmarshall ...
PAT 
AOP (JBossAOP) persistence library (aspect library). Provides persistence layer with underlying Prevayler (1.02). Allows users to write their code without worrying about persistence code (POJO). Uses annotations...
Java Object Relation 
This is a Java Object Relation mapping tool that is very simple to use. It works with all major databases and requires only minimal coding effort. JOR strictly follows the POJO / POJI (Plain Old Java Objects / Plain Old Java Interfaces) model...
AutoPersistJ 
This project aims to assist developers in developing java EE persistence layer for existing database tables. It gets metadata of selected database tables and generates classes for them. it uses and extends the ideas of DbGen project to EJB 3.0 POJO...
PojoGen 
It is a small tool to generate Java Code (a POJO) for an APPFUSE-based project from a DDL file, which is created from an ER diagram by Microsoft VISIO. It makes an APPFUSE-based project more easy to use.
Apache Felix iPOJO 
A new type of dynamic service-oriented component runtime that runs pure POJO applications on the top of OSGi plateforms. Non-functional (extra-functional) services can be added and removed at runtime.
JBoss Microcontainer 
The JBoss Microcontainer is a refactoring of JBoss's JMX Microkernel to support direct POJO deployment and standalone use outside the JBoss application server.
Naked Objects
An open source framework that auto-creates an object-oriented user interface from POJOs using the naked objects pattern.