Plain old Java object
| Industry | Software engineering |
|---|---|
| Founded | 2000 |
| Founder | Martin Fowler, Rebecca Parsons, Josh MacKenzie |
In software engineering, the term plain old Java object (POJO) refers to a conventional Java object that is not bound by specific constraints. Introduced by Martin Fowler, Rebecca Parsons, and Josh MacKenzie in 2000, this expression emphasizes the preference for simple objects rather than intricate frameworks.
Initially, "POJO" described Java objects that steer clear of established Java object models, design patterns, or frameworks. Over time, it has evolved into a language-neutral expression contrasting uncomplicated objects with elaborate frameworks.
This naming convention has been adopted for analogous ideas in various languages and platforms:
- "Plain old JavaScript object" in JavaScript
- "Plain old Ruby object" (PORO) in Ruby
- "Plain old Documentation" (pod) in Perl
- Plain old CLR object (POCO) within the .NET Framework
- "Plain old PHP object" (POPO) in PHP
- Plain old telephone service (POTS) in telephony
Definition
A POJO is ideally a Java object that adheres only to the rules set by the Java Language Specification without additional constraints. Specifically, it should avoid the following:
- Inheriting from predefined classes, for example: <syntaxhighlight lang="java">public class Foo extends javax.servlet.http.HttpServlet { ...</syntaxhighlight>
- Implementing predefined interfaces, for example: <syntaxhighlight lang="java">public class Bar implements javax.ejb.EntityBean { ...</syntaxhighlight>
- Containing predefined annotations, for example: <syntaxhighlight lang="java">@javax.persistence.Entity public class Baz { ...</syntaxhighlight>
Nonetheless, numerous frameworks that claim POJO compliance still require annotations to enable capabilities such as persistence. If the underlying class qualifies as a POJO before adding annotations and would revert to POJO status if those annotations were removed, it remains classified as a POJO. Consequently, such an object does not exhibit traits of a "Specialized Java Object" (SJO).
JavaBeans
A JavaBean represents a POJO that is serializable, possesses a no-argument constructor, and exposes its properties through standardized getter and setter methods. This design facilitates declarative property access without requiring knowledge of the bean’s specific type, thereby supporting extensive framework interoperability.
While the JavaBeans specification mandates implementing the Serializable interface, many POJOs identified as JavaBeans omit this implementation. Since Serializable serves as a marker interface without methods, this requirement is minimal.
For instance, a component in JavaServer Faces (JSF) can bind bidirectionally to a property of a POJO:
<syntaxhighlight lang="xml"> <h:inputText value="#{MyBean.someProperty}"/> </syntaxhighlight>
The corresponding POJO class:
<syntaxhighlight lang="java">public class MyBean {
private String someProperty;
public String getSomeProperty() { return someProperty; }
public void setSomeProperty(String someProperty) { this.someProperty = someProperty; }
}</syntaxhighlight>
The naming pattern automatically converts "someProperty" into accessor methods like "getSomeProperty()" and mutator methods such as "setSomeProperty(String)".
The lombok library streamlines adherence to these conventions by generating code dynamically, significantly reducing boilerplate and maintenance overhead:
<syntaxhighlight lang="java">@NoArgsConstructor public class MyBean {
@Getter @Setter private String someProperty;
}</syntaxhighlight>
Additionally, various tools produce source code or bytecode that conforms directly to these conventions, further minimizing errors and easing development efforts.
Seamless Service Integration
In modern POJO-centric architectures, frameworks deliver comprehensive capabilities by seamlessly incorporating features such as persistence, transaction management, and security through Aspect-oriented programming (AOP). This allows developers to focus exclusively on business logic using plain POJOs without embedding framework-specific dependencies.
The Spring was instrumental in introducing and popularizing this approach.
Notable enterprise technologies that utilize POJO-based designs include:
- Enterprise JavaBeans (EJB)
- Java Persistence API (JPA), along with Hibernate
- CDI (Contexts and Dependency Injection for the Java EE platform)
An illustration of a fully operational EJB bean following the POJO pattern:
<syntaxhighlight lang="java"> public class HelloWorldService {
public String sayHello() {
return "Hello, world!";
}
} </syntaxhighlight>
This example does not extend any EJB superclass, implement interfaces, or use annotations. Instead, its EJB services are specified externally through XML configuration:
<syntaxhighlight lang="xml"> <enterprise-beans>
<session>
<ejb-name>helloWorld</ejb-name>
<ejb-class>com.example.HelloWorldService</ejb-class>
<session-type>stateless</session-type>
</session>
</enterprise-beans> </syntaxhighlight>
Although XML configurations can be cumbersome and challenging to maintain, some developers prefer them over annotations, which others consider to compromise the purity of the POJO model.
Alternatively, many frameworks such as Spring, EJB, and JPA offer support for annotations either as a replacement for or in conjunction with XML. The identical EJB bean annotated looks like this:
<syntaxhighlight lang="java"> @Stateless public class HelloWorldService {
public String sayHello() {
return "Hello, world!";
}
} </syntaxhighlight>
While the use of annotations means the bean is not strictly a pure POJO, these annotations serve as passive metadata that impose minimal intrusion compared to subclassing or interface implementation. This method retains much of the straightforwardness associated with the POJO paradigm while enabling vital enterprise-level services.
Plain Old Java Interface
A Plain Old Java Interface (POJI) refers to a simple Java interface employed when more elaborate interfaces are unnecessary.