ReviseAlgo Logo

Encapsulation

POJO and Java Beans

Dissect POJO specifications, Java Bean conventions, and modern boilerplate reductions via Java Records.

Interview: Evaluates difference between POJO and Java Bean conventions, and Java Records (immutable data carriers, compact constructors, and compiler-generated code).

Last Updated: June 13, 2026 • 10 min read

Java provides different models to structure data-carrying classes. While POJOs are basic classes free of external dependencies, Java Beans follow strict structural conventions. Modern Java introduces Records as a concise, compiler-optimized solution for immutable data classes.

POJO vs. Bean

POJOs are simple classes with no dependencies. Java Beans are POJOs conforming to conventions (serializable, no-arg constructor, getters/setters).

Java Records

Introduced in Java 16, record is a special class that automatically generates final fields, constructors, accessors, and utility methods.

Boilerplate Cut

Records eliminate verbose class declarations, generating equals(), hashCode(), and toString() automatically.

POJO and Java Bean Specifications

The Java ecosystem differentiates these models based on conventions:

  • POJO (Plain Old Java Object): Any Java class that is not tied to framework-specific interfaces, annotations, or extends-chains (e.g. EJB classes). It has no special compiler rules.
  • Java Bean: A POJO that adheres to the JavaBeans specification:
    1. Must implement java.io.Serializable.
    2. Must have a public no-argument constructor.
    3. All fields must be private.
    4. Expose fields using standard naming conventions (e.g., getName() and setName()).

Modern Java Records (Java 16+)

A record is a special type of class designed to act as an immutable data carrier. By declaring: 

public record User(String name, int age) {}

The compiler automatically generates:

  • Private final fields: private final String name; and private final int age;.
  • A public constructor matching the record signature (canonical constructor).
  • Public accessor methods: name() and age() (Note: no "get" prefix is generated).
  • Implementation of equals(), hashCode(), and toString() based on all components.
  • Compact Constructors: Records allow validation inside compact constructors (e.g. public User { ... }) where parameters are validated before assignment.

Common Pitfalls

  • Attempting to mutate Java Records: Expecting records to have setters or mutable fields. Records are strictly immutable, and their fields are declared final.
  • Declaring instance variables in Records: Attempting to add extra instance fields to a record body (e.g. private String email;). Records only permit static variables inside their body; instance state must be declared in the header.

Best Practices

  • Use Records for DTOs and API payloads: Use records to represent data transfers, database projection mappings, or temporary container structures.
  • Use Java Beans for Legacy Frameworks: Use standard Java Beans when working with legacy serialization or template engines that require no-argument constructors and get/set naming patterns.

Interview-Relevant Information

Q1: What is the difference between a POJO and a Java Bean?
Answer: All Java Beans are POJOs, but not all POJOs are Java Beans. A POJO is any simple Java class. A Java Bean is a specific design convention requiring private fields, public getters/setters, a public no-arg constructor, and implementation of Serializable.

Q2: Can a Java Record extend another class? Can it implement interfaces?
Answer: A Java Record cannot extend any other class because the compiler automatically makes it extend java.lang.Record (and Java does not support multiple class inheritance). However, records can implement any number of interfaces.

Quick Checklist

Can you state the JavaBeans specification rules, declare a Java Record with validation logic inside a compact constructor, and explain why records cannot extend other classes? If yes, you understand POJOs, Beans, and Records.

Use Cases

Creating immutable Data Transfer Objects (DTOs) in modern REST APIs using Records.

Integrating with legacy Hibernate/JPA frameworks that require default constructors using Java Beans.

Common Mistakes

Attempting to add instance fields inside a record body, yielding compiler errors.

Integrating Java Records with old template engines that require getXxx() naming conventions for binding properties.