Jakarta Persistence 4.0: El mayor salto de JPA en años

Durante mucho tiempo, cuando hablábamos de persistencia en Java, hablábamos de JPA. Con la migración de Java EE a Jakarta EE, JPA pasó a llamarse Jakarta Persistence, pero durante varias versiones los cambios fueron relativamente modestos.

Con Jakarta Persistence 4.0 eso cambia.

Esta nueva versión incorpora características largamente esperadas, mejora la seguridad de tipos y prepara el terreno para trabajar junto a Jakarta Data. Veamos qué trae de nuevo.

¿Qué es Jakarta Persistence?

Jakarta Persistence es la especificación estándar para el mapeo objeto-relacional (ORM) en Java.

Permite representar tablas como objetos Java y realizar operaciones CRUD sin escribir SQL para cada interacción.

@Entity

public class Cliente {

    @Id

    private Long id;

    private String nombre;

}

Implementaciones populares incluyen:

• Hibernate ORM
• EclipseLink

Novedades más importantes de Jakarta Persistence 4.0:

1. EntityAgent: trabajar sin Persistence Context

Una de las novedades más llamativas es la incorporación de EntityAgent.

Hasta ahora, casi todas las operaciones pasaban por un EntityManager y un Persistence Context.

entityManager.persist(cliente);

Con EntityAgent se pueden realizar operaciones sobre entidades desacopladas del contexto de persistencia, simplificando ciertos escenarios y reduciendo overhead. 

Conceptualmente:

entityAgent.insert(cliente);

Esto acerca la API a modelos más ligeros y modernos.

2. Carga masiva por ID

Un problema clásico:

for(Long id : ids) {

    entityManager.find(Cliente.class, id);

}

Esto puede generar el famoso problema N+1.

Jakarta Persistence 4.0 incorpora soporte para obtener múltiples entidades por identificador en una sola operación. 

La ventaja:

• Menos viajes a la base de datos.
• Mejor rendimiento.
• Código más simple.

3. Consultas más seguras con Static Query

Una crítica frecuente a JPA era que las consultas JPQL eran simples Strings.

@Query("select c from Cliente c")

Si el nombre de una propiedad cambiaba, el error aparecía recién en tiempo de ejecución.

Persistence 4.0 incorpora una API de Static Queries que permite mayor verificación en compilación. 

Beneficios:

• Más seguridad de tipos.
• Menos errores en producción.
• Mejor soporte para herramientas y refactorización.

4. Result Set Mapping programático

Hasta ahora era habitual definir mapeos complejos mediante anotaciones.

@SqlResultSetMapping(...)

La nueva versión agrega una API programática para definir estos mappings. 

Ventajas:

• Más flexible.
• Más reutilizable.
• Menos anotaciones gigantes.

5. Nuevas capacidades para Entity Graphs

Los Entity Graphs fueron introducidos para controlar qué relaciones se cargan.

@EntityGraph(attributePaths = {

    "pedidos",

    "direccion"

})

Persistence 4.0 mejora significativamente esta funcionalidad:

Nuevas anotaciones.

Mejor integración con operaciones existentes.

Uso de Entity Graphs en refresh(). 

6. Soporte para entidades Read-Only

En muchos escenarios solo queremos leer datos.

Antes:

Cliente cliente =

    entityManager.find(Cliente.class, id);

La entidad quedaba administrada por el contexto.

Persistence 4.0 agrega soporte explícito para carga en modo solo lectura. 

Beneficios:

• Menor consumo de memoria.
• Menor costo de dirty checking.
• Mejor rendimiento.

7. @PreMerge

Hasta ahora existían callbacks como:

@PrePersist

@PostPersist

@PreUpdate

@PostUpdate

Ahora aparece:

@PreMerge

public void beforeMerge() {

    System.out.println("Fusionando entidad");

}

Esto permite interceptar el proceso de merge antes de que ocurra. 

8. Excluir campos del Optimistic Locking

Hasta ahora cualquier modificación podía afectar el control de versiones.

Persistence 4.0 incorpora una anotación para excluir ciertos atributos del mecanismo de optimistic locking. 

Ideal para:

• Campos calculados.
• Contadores.
• Metadatos auxiliares.

9. select new implícito

Actualmente:

select new ClienteDTO(

    c.id,

    c.nombre

)

from Cliente c

Persistence 4.0 simplifica este escenario permitiendo inferir automáticamente el DTO cuando se especifica el tipo de resultado. 

10. Preparándose para Jakarta Data

Quizás el cambio más importante no sea una característica puntual.

Muchas de las nuevas APIs fueron diseñadas para trabajar mejor con Jakarta Data

La idea es ofrecer una experiencia similar a:

• Spring Data
• Micronaut Data
• Quarkus Panache

pero de forma estandarizada dentro del ecosistema Jakarta EE. 

¿Vale la pena actualizar?

• Si estás usando:
• Hibernate moderno
• Jakarta EE 11 o futuro Jakarta EE 12
• Nuevos proyectos

la respuesta es sí.

Las mejoras apuntan a problemas reales que los desarrolladores vienen sufriendo desde hace años:

• Más type safety
• Menos Strings mágicos
• Mejor rendimiento
• Mejor integración con Jakarta Data
• APIs más modernas

Jakarta Persistence 4.0 representa probablemente la evolución más importante de JPA desde la llegada de los Entity Graphs y los Stored Procedures.

La incorporación de EntityAgent, Static Queries, Result Set Mapping programático, mejoras en Entity Graphs y nuevas capacidades de carga hacen que la especificación se vea mucho más moderna y preparada para competir con las soluciones de persistencia actuales. 

Para quienes pensaban que JPA había quedado estancado, Jakarta Persistence 4.0 demuestra exactamente lo contrario.

Dejo link: 

https://jakarta.ee/specifications/persistence/4.0/