Community hub
Recent from talks
Contribute something
Nothing was collected or created yet.
Plain old Java object
View on WikipediaIn 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:[1]
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.
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.[citation needed]
The term continues an acronym pattern to coin retronyms for constructs that do not use fancy new features:
- "Plain old JavaScript object" in JavaScript[2]
- "Plain old Ruby object" (PORO) in Ruby
- "Plain old Documentation" (pod) in Perl
- Plain old CLR object (POCO)[3] in the .NET Framework
- "Plain old PHP object" (POPO)[4][5] in PHP
- Plain old telephone service (POTS) in telephony
Definition
[edit]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 in
import javax.servlet.http.HttpServlet;
public class Foo extends HttpServlet {
// ...
}
- Implement prespecified interfaces, as in
import javax.ejb.EntityBean;
public class Bar implements EntityBean {
// ...
}
- Contain prespecified annotations, as in
import javax.persistence.Entity;
@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. 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
[edit]JavaBeans
[edit]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:
<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()" (or "isSomeProperty()" if the property is of Boolean type) method for getting a value, and to the "setSomeProperty(String)" method for setting a value.
The Project 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
[edit]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.[6]
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:
<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.[7]
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.[6] Accordingly, the programming model is still very much like the pure POJO model.
Related Acronyms
[edit]Plain old Java Interface
[edit]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.[8]: 57, 572, 576, 579, 1340
See also
[edit]References
[edit]- ^ "MF Bliki: POJO". MartinFowler.com.
- ^ Almaer, Dion (2006-07-17). "Return of the POJO: Plain 'Ole JavaScript". Ajaxian. Archived from the original on 2014-09-13. Retrieved 2014-08-19.
- ^ "POCO Support". microsoft.com. Retrieved 2012-05-27.
- ^ Kneschke, Jan (2007-02-19). "typesafe objects in PHP". kneschke.de. Archived from the original on 2012-03-26. Retrieved 2012-05-27.
- ^ Cheong, Jym (2011-06-26). "Controller with bare-bone Plain Old PHP Object aka POPO". jym.sg. Archived from the original on 2012-03-26. Retrieved 2012-05-27.
- ^ a b Martin, Robert C; (2008); Clean Code, Chapter 11, Pure Java AOP Frameworks
- ^ Panda, Debu; Rahman, Reza; Lane, Derek; (2007). EJB 3 in action, Manning Publications Co., Shelter Island (NY), ISBN 978-1-93-398834-4 (www.manning.com/books/ejb-3-in-action). Chapter 11, Deployment descriptors vs. annotations
- ^ Wahli, Ueli; Vieira, Miguel; Gomes, Ferreira Lopes; Hainey, Brian; Moharram, Ahmed; Napoli, JuanPablo; Rohr, Marco; Cui, Henry; Gan, Patrick; Gonzalez, Celso; Ugurlu, Pinar; Ziosi, Lara (29 June 2009). Rational Application Developer V7.5 Programming Guide. IBM Redbooks. ISBN 978-0738432892.
Plain old Java object
View on GrokipediaDefinition and Origins
Definition
A Plain Old Java Object (POJO) is an ordinary Java class that does not extend prespecified superclasses or implement interfaces mandated by particular frameworks or external technologies, though it may include annotations—even framework-specific ones like @Entity—for metadata purposes.[2][3] This design ensures the class remains lightweight, portable, and focused on core Java features for its structure and behavior, without mandatory dependencies on non-core libraries. The term "POJO" was coined in September 2000 by software engineers Martin Fowler, Rebecca Parsons, and Josh MacKenzie while preparing a presentation for the Technology of Object-Oriented Languages and Systems (TOOLS) conference.[2] They introduced it to advocate for the simplicity of ordinary Java objects in enterprise applications, contrasting them with cumbersome components like Entity Beans in early Java EE specifications, which imposed heavy dependencies and boilerplate code. A representative example of a POJO is a basic class encapsulating data with private fields and public accessor methods, free from any framework inheritance or obligations:public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
Historical Development
The term "Plain Old Java Object" (POJO) was coined in September 2000 by Martin Fowler, Rebecca Parsons, and Josh MacKenzie while preparing a conference talk, as a way to advocate for simple, lightweight Java objects in contrast to the complex, invasive requirements of early Enterprise JavaBeans (EJB) specifications that mandated specific interfaces and base classes.[2] This introduction emerged during a period when EJB 1.0 and 2.0 dominated enterprise development, often burdening developers with boilerplate code and reducing the use of straightforward Java classes.[4] The concept gained significant traction through Rod Johnson's 2002 book Expert One-on-One J2EE Design and Development, which critiqued the heaviness of EJBs and promoted POJO-based architectures for more maintainable enterprise applications. Johnson further popularized POJOs with the initial release of the Spring Framework in June 2003, which was derived from code in his book and emphasized dependency injection and aspect-oriented programming using ordinary Java objects without EJB dependencies, enabling developers to avoid proprietary container intrusions. This approach marked a pivotal shift toward inversion of control and lightweight alternatives in Java enterprise ecosystems. POJO usage evolved with Java language advancements, particularly the introduction of annotations in Java 5 (released in 2004), which allowed metadata to be added to classes without requiring inheritance or interfaces from frameworks; this enabled POJOs to integrate with tools like JPA or Spring via annotations while preserving their lightweight nature and framework-agnostic core. In the pre-Java 5 era, POJOs were strictly limited to standard Java features without such extensions; by Java 8 and later (2014 onward), annotations became commonplace for configuration, alongside features like lambda expressions and streams, without compromising POJO status. A landmark adoption occurred with EJB 3.0 in 2006, which redesigned enterprise beans as annotated POJOs managed by containers, simplifying development and aligning with the POJO philosophy by eliminating mandatory interfaces for most components.[5] The transition to Jakarta EE in the 2020s, following Oracle's donation of Java EE to the Eclipse Foundation in 2017 and the rebranding in 2019, reinforced POJO-centric simplicity by modernizing specifications for cloud-native and microservices environments, emphasizing lightweight models with minimal configuration overhead.[6][7] This evolution underscores POJOs' enduring role in promoting testable, portable Java code amid ongoing enterprise shifts toward agility and reduced framework lock-in.Key Characteristics
Core Properties
A Plain Old Java Object (POJO) is fundamentally defined by its lack of dependencies on specific framework classes or interfaces, ensuring it remains a standard Java class compliant only with the Java Language Specification.[3] This simplicity distinguishes POJOs from more complex enterprise components, such as those in early Enterprise JavaBeans (EJB) specifications, where classes were required to extend or implement proprietary elements.[2] One core property is that a POJO must not extend particular framework-specific classes, such asjavax.ejb.EntityBean, which was mandatory for entity beans in EJB 2.x to enable container-managed persistence.[8] Similarly, a POJO avoids implementing framework-specific interfaces, like javax.ejb.SessionBean, which imposed lifecycle management obligations in pre-EJB 3.0 session beans.[8] These restrictions prevent tight coupling to any application server or enterprise framework, allowing the object to function independently in various contexts.[3]
While not strictly required, POJOs often include a default no-argument constructor to facilitate instantiation by reflection-based tools, and they typically feature private fields accessed via public getter and setter methods for encapsulation.[3] Implementing java.io.Serializable is optional and only necessary if the POJO needs to support serialization for distribution or persistence, but it does not affect its POJO status.[3] The Spring Framework's advocacy for POJOs further reinforced these properties to enable non-invasive application of services like dependency injection.[9]
The following code illustrates a basic POJO structure, with private fields, a no-argument constructor, and simple getters/setters, free of any framework annotations or imports:
public class Person {
private String name;
private int age;
public Person() {
// Default no-argument constructor
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
```[](https://www.baeldung.com/java-pojo-class)
### Common Conventions
Common conventions for plain old Java objects (POJOs) often draw from established patterns to improve readability, maintainability, and integration with standard Java tools, without imposing mandatory requirements. One widely adopted practice is adherence to JavaBeans naming conventions for properties, which enhances introspection and compatibility with libraries like serialization frameworks. For instance, properties are typically accessed via getter methods named `getPropertyName()` for non-boolean types or `isPropertyName()` for booleans, and setter methods named `setPropertyName()`, allowing tools to automatically identify and manipulate object state.[](https://docs.oracle.com/cd/E19316-01/819-3669/bnais/index.html)[](https://www.baeldung.com/java-pojo-javabeans-dto-vo)
To reduce [boilerplate code](/page/Boilerplate_code) while preserving POJO simplicity, developers frequently use annotation processors like Project Lombok, which generate standard methods at [compile time](/page/Compile_time) without runtime dependencies or framework ties. The `@Data` annotation, for example, automatically produces getters, setters, `toString()`, `equals()`, and `hashCode()` implementations following [JavaBeans](/page/JavaBeans) patterns, ensuring the resulting class remains a lightweight POJO suitable for any [Java](/page/Java) environment.[](https://projectlombok.org/features/Data)[](https://auth0.com/blog/a-complete-guide-to-lombok/)
Since [Java](/page/Java) 16, [records](/page/The_Records) provide a built-in [language](/page/Language) feature for creating immutable POJOs concisely. [Records](/page/The_Records) are final classes that automatically generate a [canonical](/page/Canonical) constructor, private final fields, public accessor methods, and implementations of `equals()`, `hashCode()`, and `toString()`, promoting immutability and reducing boilerplate without any external dependencies. They are particularly useful for data carrier classes in modern [Java](/page/Java) applications ([Java](/page/Java) 16 and later). For example:
```java
public record Person([String](/page/String) name, int age) {}
public class Person {
private String name;
private int age;
public Person() {
// Default no-argument constructor
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
```[](https://www.baeldung.com/java-pojo-class)
### Common Conventions
Common conventions for plain old Java objects (POJOs) often draw from established patterns to improve readability, maintainability, and integration with standard Java tools, without imposing mandatory requirements. One widely adopted practice is adherence to JavaBeans naming conventions for properties, which enhances introspection and compatibility with libraries like serialization frameworks. For instance, properties are typically accessed via getter methods named `getPropertyName()` for non-boolean types or `isPropertyName()` for booleans, and setter methods named `setPropertyName()`, allowing tools to automatically identify and manipulate object state.[](https://docs.oracle.com/cd/E19316-01/819-3669/bnais/index.html)[](https://www.baeldung.com/java-pojo-javabeans-dto-vo)
To reduce [boilerplate code](/page/Boilerplate_code) while preserving POJO simplicity, developers frequently use annotation processors like Project Lombok, which generate standard methods at [compile time](/page/Compile_time) without runtime dependencies or framework ties. The `@Data` annotation, for example, automatically produces getters, setters, `toString()`, `equals()`, and `hashCode()` implementations following [JavaBeans](/page/JavaBeans) patterns, ensuring the resulting class remains a lightweight POJO suitable for any [Java](/page/Java) environment.[](https://projectlombok.org/features/Data)[](https://auth0.com/blog/a-complete-guide-to-lombok/)
Since [Java](/page/Java) 16, [records](/page/The_Records) provide a built-in [language](/page/Language) feature for creating immutable POJOs concisely. [Records](/page/The_Records) are final classes that automatically generate a [canonical](/page/Canonical) constructor, private final fields, public accessor methods, and implementations of `equals()`, `hashCode()`, and `toString()`, promoting immutability and reducing boilerplate without any external dependencies. They are particularly useful for data carrier classes in modern [Java](/page/Java) applications ([Java](/page/Java) 16 and later). For example:
```java
public record Person([String](/page/String) name, int age) {}
final fields initialized solely through constructors to prevent state changes after creation, thereby guaranteeing thread-safety without synchronization overhead. This approach aligns with core Java principles and avoids mutable state issues, making such POJOs ideal for sharing across threads. Records exemplify this pattern natively.[11]
For data integrity, POJOs may incorporate optional validation annotations from the Jakarta Bean Validation API (formerly javax.validation), such as @NotNull or @Size, applied directly to fields or properties; these are processed at runtime using a standalone validator like Hibernate Validator, without requiring framework enforcement. This practice enables declarative constraints that promote robust object models in plain Java applications.[12]
Best practices emphasize keeping POJOs focused on a single responsibility, such as representing domain data, while avoiding static dependencies on external frameworks to maintain portability and testability. Classes should encapsulate only essential fields and methods, eschewing complex logic or third-party integrations that could violate the plain Java ethos.[13][14]
Contextual Variations
As JavaBeans
A Plain Old Java Object (POJO) serves as a superset that encompasses JavaBeans, where the latter adheres to specific conventions for reusability and introspection within the Java platform. To qualify as a JavaBean, a POJO must provide a public no-argument constructor for instantiation by tools or containers, and follow accessor patterns with private fields accessed via public getter and setter methods. It is conventional for a JavaBean to implement theSerializable interface to enable persistence and object serialization, though this is not strictly required.[15] These requirements ensure compatibility with Java's component model without imposing dependencies on external frameworks, maintaining the "plain" nature of the object.[3]
Introspection in JavaBeans is facilitated by the java.beans package, which allows development tools to automatically discover and manipulate a bean's properties, methods, and events through reflection. The Introspector class in this package analyzes the class hierarchy to identify design patterns, such as getter/setter pairs for properties, and can be customized using a BeanInfo implementation to provide explicit descriptors for non-standard features.[16][17] This mechanism enables tools like IDEs or builders to interact with the POJO as a JavaBean without requiring additional configuration, all while relying solely on core Java APIs.
JavaBeans extend POJOs to support events and bound properties, allowing other objects to listen for changes without framework involvement. Bound properties notify registered listeners of modifications via the PropertyChangeListener interface, implemented through the PropertyChangeSupport class to fire PropertyChangeEvent instances when a property value updates.[18][15] This event model promotes loose coupling, as listeners can be added or removed dynamically using standard methods like addPropertyChangeListener, ensuring the POJO remains self-contained and portable.
The following example illustrates a POJO fully conforming to JavaBeans specifications: a simple Person class with a bound name property, serialization support, a no-argument constructor, and standard accessors.
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
import java.io.Serializable;
public class Person implements Serializable {
private String name;
private final PropertyChangeSupport support = new PropertyChangeSupport(this);
public Person() {
// No-argument constructor
}
public String getName() {
return name;
}
public void setName(String name) {
String oldName = this.name;
this.name = name;
support.firePropertyChange("name", oldName, name);
}
public void addPropertyChangeListener(PropertyChangeListener listener) {
support.addPropertyChangeListener(listener);
}
public void removePropertyChangeListener(PropertyChangeListener listener) {
support.removePropertyChangeListener(listener);
}
}
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
import java.io.Serializable;
public class Person implements Serializable {
private String name;
private final PropertyChangeSupport support = new PropertyChangeSupport(this);
public Person() {
// No-argument constructor
}
public String getName() {
return name;
}
public void setName(String name) {
String oldName = this.name;
this.name = name;
support.firePropertyChange("name", oldName, name);
}
public void addPropertyChangeListener(PropertyChangeListener listener) {
support.addPropertyChangeListener(listener);
}
public void removePropertyChangeListener(PropertyChangeListener listener) {
support.removePropertyChangeListener(listener);
}
}
java.beans package, and used to notify listeners of property changes, all using built-in Java features.[15]
While JavaBeans conventions enhance introspection and event handling, they introduce minor overhead during reflection-based analysis, such as class hierarchy traversal by the Introspector. However, this remains inherent to standard Java and does not require external tools, preserving the POJO's simplicity and independence.[16]
With Added Services
Frameworks such as Spring and Jakarta EE enable the enhancement of POJOs with enterprise services like transaction management, security, and persistence through transparent mechanisms, preserving the object's simplicity and avoiding invasive modifications to its core structure.[19][5] In the Spring Framework, Aspect-Oriented Programming (AOP) allows developers to add cross-cutting concerns, such as logging or transaction management, to POJOs without altering their code. Spring AOP uses proxy-based interception to apply aspects at runtime, enabling services like declarative transaction handling via proxies around POJO methods.[19] This non-invasive approach ensures POJOs remain lightweight while integrating enterprise features. Modern frameworks leverage annotations to augment POJOs with services, exemplified by the @Entity annotation in Jakarta Persistence API (JPA), introduced post-EJB 3.0. This annotation designates a POJO as a persistent entity, mapping it to a database table without requiring inheritance from framework-specific classes or implementing special interfaces, thus maintaining its POJO status.[5] Services like object-relational mapping and query execution are then applied transparently by the JPA provider at runtime.[20] Dependency injection further enhances POJOs by wiring dependencies externally, as seen in Spring's @Autowired annotation, which injects required services into POJO fields, constructors, or setters without embedding container-specific logic.[21] This can be configured via annotations or XML, allowing the Spring container to manage object lifecycles and resolve dependencies at runtime, keeping the POJO free of direct service lookups.[21] For instance, consider a domain object representing a customer:import jakarta.persistence.Entity;
import jakarta.persistence.Id;
@Entity
public class Customer {
@Id
private Long id;
private String name;
// Constructors, getters, setters
public Customer() {}
public Customer(Long id, String name) {
this.id = id;
this.name = name;
}
// Getters and setters...
}
import jakarta.persistence.Entity;
import jakarta.persistence.Id;
@Entity
public class Customer {
@Id
private Long id;
private String name;
// Constructors, getters, setters
public Customer() {}
public Customer(Long id, String name) {
this.id = id;
this.name = name;
}
// Getters and setters...
}
Comparisons and Related Concepts
Versus JavaBeans and EJBs
A Plain Old Java Object (POJO) encompasses a wider scope than a JavaBean, as it imposes no mandatory conventions beyond standard Java class requirements, whereas a JavaBean is a specialized subset of POJOs designed for reusable component architectures with specific introspection and interaction patterns.[23] JavaBeans must adhere to design conventions outlined in the JavaBeans specification, including a public no-argument constructor, property access via getter and setter methods following naming patterns (e.g.,getPropertyName() and setPropertyName()), and support for events through listener interfaces.[15] While serialization via the java.io.Serializable interface is recommended for JavaBeans to enable persistence and transport in component environments, it is not strictly required for all implementations, distinguishing JavaBeans as POJOs tailored for builder tools and GUI frameworks like Swing.[24]
In contrast to POJOs, Enterprise JavaBeans (EJBs) prior to version 3.0 were inherently non-POJOs due to stringent requirements for container-managed lifecycle, including mandatory implementation of interfaces such as javax.ejb.SessionBean or javax.ejb.EntityBean, definition of home and remote interfaces, and configuration via XML deployment descriptors like ejb-jar.xml.[25] These elements tied EJBs tightly to the EJB container for services like transaction management and security, preventing standalone instantiation or use outside an application server.[26] Starting with EJB 3.0, the specification evolved to a lightweight POJO programming model, eliminating the need for those interfaces and descriptors in favor of metadata annotations (e.g., @Stateless or @Entity), allowing EJBs to function as annotated POJOs while retaining container-provided enhancements.[27]
Modern EJBs exhibit significant overlap with POJOs, employing POJO-like class structures augmented by annotations to inject enterprise services such as dependency injection and persistence, thereby bridging simplicity with distributed computing capabilities.[28] POJOs provide key advantages over traditional EJBs, including enhanced portability across non-EJB environments, simplified unit testing without an application server, and lower coupling to framework-specific APIs, which facilitates code reuse in varied contexts like Spring or standalone applications.[29]
| Aspect | POJO | JavaBean | EJB |
|---|---|---|---|
| Constructor | Any valid Java constructor | Public no-argument constructor required | Public no-argument constructor required |
| Interfaces | None required | None required, but supports event listener interfaces for customization | Pre-3.0: Specific interfaces (e.g., SessionBean); Post-3.0: None required, annotations suffice |
| Framework Dependency | None; standalone executable | Minimal; optional BeanInfo for advanced introspection | Container mandatory for services; pre-3.0 heavy, post-3.0 lightweight via annotations |
| Configuration | None; plain Java code | Naming conventions for properties/events; no descriptors | Pre-3.0: XML deployment descriptors required; Post-3.0: Optional annotations or XML |
Plain Old Java Interface (POJI)
A Plain Old Java Interface (POJI) is defined as a standard Java interface that imposes no special restrictions, does not extend framework-specific superinterfaces, and avoids annotations or dependencies tied to particular technologies or containers.[30] This simplicity mirrors the POJO concept for classes, emphasizing portability and ease of use across different environments without requiring adherence to enterprise framework conventions.[31] The term POJI was coined in the early 2000s, emerging around 2004 in discussions related to simplifying enterprise Java development, particularly with the evolution toward EJB 3.0 specifications released in 2006, to promote lightweight contracts suitable for dependency injection and modular design.[32] It gained traction as frameworks like Spring and EJB shifted toward POJO/POJI-based programming to reduce boilerplate and enhance testability.[33] Key characteristics of a POJI include declaring only public abstract methods prior to Java 8, ensuring the interface serves purely as a contract without implementations. With Java 8 and later, default and static methods are permitted, provided they remain free of framework-specific logic to maintain the "plain old" nature.[34] These features allow POJIs to evolve while preserving compatibility and avoiding ties to legacy enterprise patterns like those in earlier EJB versions. In the Spring Framework, POJIs are commonly employed to define service layers, repositories, and gateways, fostering loose coupling via dependency injection where implementations can be swapped without altering the interface. For instance, Spring Integration uses POJIs for messaging gateways to abstract underlying transport details, enabling developers to focus on business logic.[35] A representative example is a basic repository interface for data access:public interface UserRepository {
void save(User user);
User findById(Long id);
}
public interface UserRepository {
void save(User user);
User findById(Long id);
}