The best way to use Java Records with JPA and Hibernate

Introduction

In this article, I’m going to show you how you can useJava Records with JPA and Hibernate.

Added since version 14 as a preview feature, Java Records allow us to create compact DTOs (Data Transfer Objects) or Value Objects.

Domain Model

Let’s assume we have the following Post entity class in our application:

Notice that the Post entity uses theFluent-style API, which allows us to build entity instances like this:

entityManager.persist(
    new Post()
        .setId(1L)
        .setTitle("High-Performance Java Persistence")
        .setCreatedBy("Vlad Mihalcea")
        .setCreatedOn(
            LocalDateTime.of(2016, 11, 2, 12, 0, 0)
        )
        .setUpdatedBy("Vlad Mihalcea")
        .setUpdatedOn(
            LocalDateTime.now()
        )
);
entityManager.persist(
    new Post()
        .setId(2L)
        .setTitle("Hypersistence Optimizer")
        .setCreatedBy("Vlad Mihalcea")
        .setCreatedOn(
            LocalDateTime.of(2020, 3, 19, 12, 0, 0)
        )
        .setUpdatedBy("Vlad Mihalcea")
        .setUpdatedOn(
            LocalDateTime.now()
        )
);

Can Java Records be used as JPA or Hibernate entities?

One very common question is if Java records are going to simplify the way we are building JPA or Hibernate entities. And, the answer is no. They will not.

According to the JPA specification, an entity must follow these requirements:

• the entity class needs to be non- final ,
• the entity class needs to have a no-arg constructor that is either public or protected ,
• the entity attributes must be non- final .

However, as explained bythis article, the Java Record type is defined like this:

final
final

So, a Java Record cannot be used as an entity.

More, even if Hibernate relaxed these requirements, a Java Record would defeat the purpose of translating entity state transitions into SQL statements.

 A Java Record is not suitable to be used as a JPA or Hibernate entity. 

Using Java Records as DTOs

Let’s assume we have the following PostInfo and AuditInfo DTO classes:

With Java Records, we can define the AuditInfo like this:

public record AuditInfo(
    LocalDateTime createdOn,
    String createdBy,
    LocalDateTime updatedOn,
    String updatedBy
) {}

and the PostInfo looks as follows:

public record PostInfo(
    Long id,
    String title,
    AuditInfo auditInfo
) {}

Now, to use the simple class name instead of the fully-qualified one in JPQL queries, we are going to register the AuditInfo and PostInfo Java Records using the ClassImportIntegrator provided by the Hibernate Types project :

properties.put(
    "hibernate.integrator_provider",
    (IntegratorProvider) () -> Collections.singletonList(
        new ClassImportIntegrator(
            Arrays.asList(
                AuditInfo.class,
                PostInfo.class
            )
        )
    )
);

For more details about the ClassImportIntegrator utility, check outthis article.

Using Java Records in JPA constructor expression queries

To fetch an AuditInfo DTO projection for a given Post , we can use the following JPQL query:

AuditInfo auditInfo = entityManager.createQuery("""
    select 
        new AuditInfo (
            p.createdOn,
            p.createdBy,
            p.updatedOn,
            p.updatedBy
        )
    from Post p
    where p.id = :postId
    """, AuditInfo.class)
.setParameter("postId", 1L)
.getSingleResult();

Thanks to multiline Java Text Blocks , the JPQL query is very straight-forward.

While you can also fetch the AuditInfo using as @SqlResultSetMapping , neither the JPQL constructor Expression nor the the @SqlResultSetMapping allows you to fetch the PostInfo as you need to pass a properly instantiated AuditInfo reference in the PostInfo constructor.

Using Java Records using the Hibernate ResultTransformer

Where JPA falls short, Hibernate comes to the rescue. Thanks to the [ ResultTransformer](https://vladmihalcea.com/hibernate-resulttransformer/) Hibernate feature, you can fetch the PostInfo and AuditInfo` Java Records together:

List<PostInfo> postInfos = entityManager.createQuery("""
    select 
        p.id,
        p.title,
        p.createdOn,
        p.createdBy,
        p.updatedOn,
        p.updatedBy
    from Post p
    order by p.id
    """)
.unwrap(Query.class)
.setResultTransformer(
    (ListResultTransformer) (tuple, aliases) -> {
        int i =0;
        return new PostInfo(
            ((Number) tuple[i++]).longValue(),
            (String) tuple[i++],
            new AuditInfo(
                (LocalDateTime) tuple[i++],
                (String) tuple[i++],
                (LocalDateTime) tuple[i++],
                (String) tuple[i++]
            )
        );
    }
)
.getResultList();

Thanks to the ListResultTransformer utility, that’s also offered by the amazing Hibernate Types project , we can use a Java Lambda function to define the Hibernate ResultTransformer logic.

For more details about DTO projections with JPA and Hibernate, check outthis article.

I'm running an online workshop on the 14th of May about The Best Way to Fetch Data with Java Persistence and Hibernate .

If you enjoyed this article, I bet you are going to love my Book and Video Courses as well.

Conclusion

So, while Java Records are not suitable for mapping JPA and Hibernate entities, they are very useful for DTO projections.

Fetching DTOs is a very common requirement for read-only data that needs to be feed to the UI layer, so Java Records can ease the process of defining DTO projections.