Java Records - Interview Notes (Q&A)¶

1. What is a Record in Java?¶

Answer:

A Record is a special type of class introduced in Java 16 (preview in Java 14) that is designed to model immutable data. It automatically generates common methods like constructors, accessors, equals(), hashCode(), and toString(), reducing boilerplate code.

Example:

public record User(Long id, String name, String email) {}

2. Why were Records introduced?¶

Answer:

Records were introduced to eliminate repetitive boilerplate code in data-only classes.

Before records, developers had to manually write:

• Fields
• Constructor
• Getters
• equals()
• hashCode()
• toString()

Records generate all of these automatically.

3. What problem do Records solve?¶

Answer:

They simplify classes whose primary purpose is to hold data.

Instead of writing 50–100 lines of code for a simple DTO, you can write:

public record User(Long id, String name) {}

4. What methods does Java automatically generate?¶

Answer:

For

public record User(Long id, String name) {}

Java generates:

• Constructor
• id()
• name()
• equals()
• hashCode()
• toString()

5. Are Records immutable?¶

Answer:

Yes.

All fields are:

• private
• final

There are no setters.

Once a record object is created, its state cannot be changed.

6. Can Records have constructors?¶

Answer:

Yes.

They support compact constructors for validation.

Example:

public record Employee(String name, double salary) {

    public Employee {
        if (salary < 0) {
            throw new IllegalArgumentException("Salary cannot be negative");
        }
    }
}

7. Can Records contain methods?¶

Answer:

Yes.

Example:

public record Employee(String firstName, String lastName) {

    public String fullName() {
        return firstName + " " + lastName;
    }
}

8. Can Records extend another class?¶

Answer:

No.

Records automatically extend:

java.lang.Record

Since Java supports only single inheritance, records cannot extend any other class.

However, they can implement interfaces.

Example:

public record User(Long id, String name) implements Serializable {}

9. Do Records replace POJOs?¶

Answer:

Not entirely.

They replace data-only POJOs.

Good candidates:

• DTO
• Value Objects
• API Response Objects
• Configuration Objects

Not suitable for:

• Service classes
• Business logic classes
• Mutable objects

10. Do Records replace DTOs?¶

Answer:

Yes, in most modern applications.

Instead of:

public class UserDTO {
    private Long id;
    private String name;
}

Use:

public record UserDTO(Long id, String name) {}

Records are now commonly used for request and response DTOs.

11. Do Records replace Wrapper classes?¶

Answer:

No.

Wrapper classes are:

• Integer
• Long
• Double
• Boolean

They wrap primitive types.

Records are a completely different feature used for modelling immutable objects.

12. Can Records be used as JPA Entities?¶

Answer:

Generally, No.

JPA entities require:

• Mutable fields
• No-argument constructor
• Hibernate proxies

Records are immutable and don't meet these requirements.

Best practice:

• Entity → Normal class
• DTO → Record

13. Can Records be used in Spring Boot?¶

Answer:

Yes.

They are excellent for:

• Request DTOs
• Response DTOs
• Configuration Properties
• Event Objects

Example:

public record UserRequest(
    String name,
    String email
) {}

14. Can Records be used with MapStruct?¶

Answer:

Yes.

MapStruct fully supports records.

Example:

@Mapper(componentModel = "spring")
public interface UserMapper {

    UserResponse toResponse(User user);

}

15. Can Records be used in manual mapping?¶

Answer:

Yes.

Example:

public UserResponse toResponse(User user) {

    return new UserResponse(
        user.getId(),
        user.getName(),
        user.getEmail()
    );

}

16. Why use Entity → DTO mapping?¶

Answer:

Never expose database entities directly.

Benefits:

• Hide sensitive fields (password)
• Decouple API from database
• Better security
• Easier maintenance

Flow:

Entity
   ↓
Mapper
   ↓
DTO (Record)
   ↓
JSON Response

17. What is the difference between an Entity and a Record?¶

18. How do you access Record fields?¶

Unlike traditional getters:

user.getName();

Records use accessor methods named after the component:

user.name();

19. What are the advantages of Records?¶

Answer:

• Less boilerplate
• Immutable by default
• Thread-safe for their own state
• Cleaner code
• Built-in equals()
• Built-in hashCode()
• Built-in toString()
• Great for REST APIs
• Easy to read and maintain

20. What are the limitations of Records?¶

Answer:

• Cannot extend another class
• Cannot have mutable instance fields
• Not suitable for JPA entities
• Cannot declare additional instance fields (only static fields are allowed beyond the record components)
• Not suitable for objects with frequently changing state

21. When should you use Records?¶

Use Records when:

• Creating DTOs
• API Request objects
• API Response objects
• Value Objects
• Configuration classes
• Event Messages
• Immutable models

22. When should you NOT use Records?¶

Avoid records for:

• JPA Entities
• Service classes
• Business logic classes
• Objects with mutable state
• Classes requiring inheritance

23. Real-world Spring Boot architecture¶

Controller
      │
      ▼
Request DTO (Record)
      │
      ▼
Mapper
      │
      ▼
Entity
      │
      ▼
Repository
      │
      ▼
Database
      │
      ▼
Entity
      │
      ▼
Mapper
      │
      ▼
Response DTO (Record)
      │
      ▼
JSON Response

⭐ Interview Summary (30-second answer)¶

"Java Records are immutable data carrier classes introduced to reduce boilerplate code. They automatically generate constructors, accessor methods, equals(), hashCode(), and toString(). Records are best suited for DTOs, API request/response models, configuration objects, and value objects. They are not intended to replace JPA entities because entities need to be mutable and compatible with the JPA lifecycle. In modern Spring Boot applications, a common pattern is to keep entities as regular classes, use records for DTOs, and map between them using MapStruct or manual mappers."

This concise explanation covers the purpose, benefits, limitations, and common real-world usage—exactly what interviewers often look for.