Recordatorios sobre elementos externos a Spring

Codificación equals y hashCode

La igualdad de objetos es importante en Spring, especialmente para las arquitecturas que usan Spring junto con un mapping objeto-relacional (en inglés Object-Relational Mapping u ORM) como Hibernate y JPA.

De hecho, como detallaremos más adelante, en Spring, Hibernate y JPA hay nociones de proxy. Cuando tenemos dos objetos en memoria, hemos de tener cuidado de no comparar un proxy con el objeto al que representa.

Del mismo modo, dos objetos pueden ser idénticos desde un punto de vista de negocio, pero se corresponden con dos objetos distintos en la memoria. Veremos que este aspecto es crucial a la hora de utilizar colecciones.

Una definición según Java nos muestra lo que se espera de los métodos equals y hashCode. A partir de esta definición, veremos cómo adaptar este concepto para su uso en una arquitectura que hace uso masivo de proxys y listas, como Spring, JPA e Hibernate.

En este capítulo, usaremos «equals» para hacer referencia al método equals y «hashcode» para designar el método hashCode.

A continuación, se presenta una traducción aproximada de la documentación oficial para equals y hashCode.

equals

public boolean equals(Object obj) 

Indica si un objeto es igual al que se pasa como parámetro.

El método equals implementa una relación de equivalencia entre dos referencias de objeto no nulas.

Es reflexivo: para cualquier referencia de un valor no nulo x, x.equals(x) debe devolver true.

Es simétrico: para cualquier referencia de un valor no nulo x e y, x.equals(y) devuelve true si y solo si y.equals(x) devuelve true.

Es transitivo: para cualquier referencia de un valor no nulo x, y y z, si x.equals(y) devuelve true e y.equals(z) devuelve true, entonces x.equals(z) debe devolver true.

Es consistente: para cualquier referencia de un valor no nulo x e y, múltiples invocaciones a x.equals(y) siempre devuelven true o consistentemente false si no se modifica la información proporcionada utilizada en las comparaciones de igualdad en los objetos.

Para una referencia no nula en un valor x, x.equals(null) debe devolver false.

El método equals para la clase Object implementa la relación...

Proyecto Lombok

La librería del proyecto Lombok (https://projectlombok.org/) simplifica mucho el diseño de los POC porque minimiza el código. La mayoría de mis clientes lo usan en producción, al igual que los ejemplos de código de este libro, para reducir el tamaño del código. Es muy fácil eliminarlo y utilizar las facilidades de generación de código de su IDE (Integrated Development Environment), en general Eclipse o IntelliJ IDEA, y, si es necesario, añadir la declaración del logger.

De hecho, gracias a esta librería, podemos utilizar anotaciones que inyectan código sobre la marcha para realizar tareas comunes como los logs, descriptores de acceso, constructores y muchas otras utilidades.

Para utilizar la librería del proyecto Lombok, debe añadir la dependencia en el archivo pom.xml:

<dependency> 
   <groupId>org.projectlombok</groupId> 
   <artifactId>lombok</artifactId> 
   <version>${lombok.version}</version> 
</dependency> 

Si usa Eclipse, debe parchear su entorno Eclipse como se indica en el sitio web del proyecto Lombok. Para hacer esto, ejecute el JAR de la librería desde la línea de comandos y seleccione su Eclipse para parchear. El archivo INI de Eclipse especifica el JAR que se cargará durante el arranque....

Sistemas de registro de actividad o log

Log4j, SLF4J y Logback

Durante muchos años, se ha utilizado el sistema de registro Log4j de manera tradicional para registrar mensajes de información, depuración y error. Sin embargo, la nueva librería Logback (http://logback.qos.ch/) es mucho más potente que Log4j.

Con Log4j, debe prestar atención a los problemas de seguridad que se detectaron en la versión anterior a la 2.17.

Históricamente, JCL (Jakarta Common Logging) fue una de las primeras API concurrentes, pero siguió siendo muy limitada. Alrededor de 2006, grandes proyectos como Hibernate adoptaron la API SLF4J (http://www.slf4j.org/), que la popularizó. Sin embargo, a pesar de un buen comienzo, SLF4J no eclipsó totalmente a Log4j.

Sin embargo, gracias a SLF4J, es posible centralizar en un único conjunto de archivos de registro las llamadas que realizan las diferentes API de registro, como JCL, Log4j, JUL (http://docs.oracle.com/javase/8/docs/api/java/util/logging/package-summary.html), etc.

En la actualidad, se agrupan los registros de las llamadas a las API de log y es posible elegir qué implementación de registro utilizar. A diferencia de JCL, que carga las librerías en tiempo de ejecución con el classloader, SLF4J elige la implementación de destino del paquete correspondiente al puente de software entre los tipos de API.

La API Logback de sesión...

Bases de datos H2

Proyectos Maven

El framework Java ofrece un JDK básico lleno de API, lo que facilita la creación de librerías y su uso compartido. Han aparecido muchas librerías.

Estas librerías usan otras librerías y, al final, terminamos con dependencias. Las cosas se complican cuando, por ejemplo, tenemos dos librerías que usan otras dos librerías, pero en diferentes versiones. Entonces, el juego consiste en encontrar la combinación correcta. El orden de carga también es muy importante, porque en los servidores JEE las librerías del servidor tienen prioridad sobre las librerías de la aplicación.

Por supuesto, es posible invertir la prioridad cargando primero las librerías de aplicación antes que las del servidor, pero entonces perdemos el soporte del proveedor del servidor de aplicaciones. Por lo general, tenemos un directorio para las librerías del servidor y otro para las librerías de cada proyecto.

Spring y las versiones de Java

Las versiones de Spring siempre han sido compatibles con las versiones de Java que están activas en el momento de la publicación de la versión. Algunas veces, Spring estaba ligeramente por delante.

Java

Spring

En el GitHub de Spring, para las versiones soportadas se especifica:

La versión 5.3.x es la última feature branch de la 5.ª generación y la última línea de producto (GA a partir de octubre de 2020), con soporte a largo plazo proporcionado para JDK 8, JDK 11 y JDK 17.

La versión 5.2.x es la línea de producto anterior (GA a partir de septiembre de 2019), que se soportará de manera activa hasta finales de 2021.

Las versiones 5.1.x y 5.0.x ya no son compatibles de manera activa, sino que se sustituyen por 5.2.x y 5.3.x a partir de diciembre de 2020.

La versión 4.3.x alcanzó el final de su vida oficial (EOL) el 31 de diciembre de 2020. No se prevén otros parches de mantenimiento o seguridad en esta línea.

La versión 3.2.x alcanzó el final de su vida oficial (EOL) el 31 de diciembre de 2016. No se prevén otros parches de mantenimiento o seguridad en esta línea.

En este punto, Spring recomienda que actualicemos a la última versión de Spring Framework 5.3.x desde Maven Central.

Gama de versiones del JDK:

Spring Framework 6.0.x: JDK 17-21 (esperado)...