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/

Introducción a Jakarta NoSQL

EE4J no se detiene y ha aprobado el proyecto Jakarta NoSQL es una especificación en Jakarta EE para ayudar a los desarrolladores a crear aplicaciones de nivel empresarial utilizando tecnologías Java y NoSQL. JNoSQL es la implementación de referencia de Jakarta NoSQL, que proporciona un conjunto de APIs y una implementación estándar para una serie de bases de datos NoSQL, como Cassandra, MongoDB, Neo4J, CouchDB y OrientDB, entre otras.

Jakarta NoSQL consiste en una capa de comunicación (Diana), que extrae un conjunto de APIs diseñadas para definir la comunicación con las bases de datos NoSQL. Contiene cuatro módulos de acuerdo con cada tipo de base de datos NoSQL: clave-valor, familia de columnas, documento y grafo; y una capa de mapeo (Artemis), que proporciona una serie de APIs para ayudar a los desarrolladores a integrar aplicaciones Java con bases de datos NoSQL. La capa de mapeo se basa en anotaciones y utiliza tecnologías como CDI y Bean Validation, lo que facilita el uso de los desarrolladores. Es posible comparar la capa de mapeo con JPA / Hibernate en el mundo tradicional RDBMS.

La definición de una entidad es relativamente similar a JPA. Básicamente usa @Entity, @Id, @Column y así sucesivamente:

@Entity
public class Person {

  @Id
  private long id;

  @Column
  private String name;

  @Column
  private List phones;
}

Los repositorios se parecen a los repositorios de Spring Data, donde se extiende un Repositorio <T, ID>:

public interface PersonRepository extends Repository {

  List<Person> findByName(String name);

  Stream<Person> findByPhones(String phone);
}

Sin embargo, a partir de este momento, las cosas cambian, ya que las dependencias de Maven cambian de acuerdo con el tipo de base de datos NoSQL que se usa, así como la configuración  y cómo inyectamos el repositorio en nuestros servicios.

Veamos 2 ejemplos, uno utilizando una base orientada a columna y otra documental. Importamos librerías :

<dependency>
   <groupId>org.jnosql.artemis</groupId>
   <artifactId>artemis-column</artifactId>
   <version>0.0.9</version>
</dependency>
<dependency>
   <groupId>org.jnosql.diana</groupId>
   <artifactId>cassandra-driver</artifactId>
   <version>0.0.9</version>
</dependency>

Veamos el manager de nuestra base orientada a columna :

@ApplicationScoped
public class ColumnFamilyManagerProducer {

  private static final String KEY_SPACE = "developers";
  private ColumnConfiguration<> cassandraConfiguration;
  private ColumnFamilyManagerFactory managerFactory;

  @PostConstruct
  public void init() {
    cassandraConfiguration = new CassandraConfiguration();
    managerFactory = cassandraConfiguration.get();
  }

  @Produces
  public ColumnFamilyManager getManagerCassandra() {
    return managerFactory.get(KEY_SPACE);
  }
}

Y finalmente, un ejemplo de cómo ejecutar algunas inserciones / consultas:

Person person = Person.builder()
  .withPhones(Arrays.asList("234", "432"))
  .withName("Name")
  .withId(id)
  .build();

//using ColumnTemplate
ColumnTemplate columnTemplate =  container.select(CassandraTemplate.class).get();
Person saved = columnTemplate.insert(PERSON);
System.out.println("Person saved" + saved);

ColumnQuery query = select().from("Person").where(eq(Column.of("id", 1L))).build();

Optional<Person> person = columnTemplate.singleResult(query);
System.out.println("Entity found: " + person);

//using PersonRepository
PersonRepository repository = container.select(PersonRepository.class).select(ofColumn()).get();
Person saved = repository.save(PERSON);
System.out.println("Person saved" + saved);

Optional<Person> person = repository.findById(1L);
System.out.println("Entity found: " + person);

Veamos un ejemplo con una base documental, primero las dependencias:

<dependency>
   <groupId>org.jnosql.artemis</groupId>
   <artifactId>artemis-document</artifactId>
   <version>0.0.9</version>
</dependency>
<dependency>
   <groupId>org.jnosql.diana</groupId>
   <artifactId>mongodb-driver</artifactId>
   <version>0.0.9</version>
</dependency>

Luego el manager :

@ApplicationScoped
public class DocumentCollectionManagerProducer {

  private static final String COLLECTION = "developers";
  private DocumentConfiguration configuration;
  private DocumentCollectionManagerFactory managerFactory;

  @PostConstruct
  public void init() {
    configuration = new MongoDBDocumentConfiguration();
    Map<String, Object> settings = Collections.singletonMap("mongodb-server-host-1", "localhost:27017");
    managerFactory = configuration.get(Settings.of(settings));
  }

  @Produces
  public DocumentCollectionManager getManager() {
    return managerFactory.get(COLLECTION);
  }
}

y usamos el manager :

Person person = Person.builder()
  .withPhones(Arrays.asList("234", "432"))
  .withName("Name")
  .withId(id)
  .build();

//using DocumentTemplate
DocumentTemplate documentTemplate = container.select(DocumentTemplate.class).get();
Person saved = documentTemplate.insert(person);
System.out.println("Person saved" + saved);

DocumentQuery query = select().from("Person")
  .where(eq(Document.of("_id", id))).build();

Optional<Person> personOptional = documentTemplate.singleResult(query);
System.out.println("Entity found: " + personOptional);

//using PersonRepository
PersonRepository repository = container.select(PersonRepository.class)
  .select(ofDocument()).get();
repository.save(person);

List<Person> people = repository.findByName("Name");
System.out.println("Entity found: " + people);
repository.findByPhones("234").forEach(System.out::println);

Y listo!

Ustedes pensaran que feo tener diferentes modos de guardar y recuperar datos de nuestros almacenes de datos sql pero tengamos en cuenta que es el único camino para aprovechar al máximo sus particularidades y normalmente elegimos estas bases por sus particularidades.

Dejo link: https://github.com/eclipse-ee4j/nosql