Qué hay de nuevo en Spring IO 2022.

Spring IO es uno de los eventos más importantes de la comunidad del software en España. Desde 2010 se ha erigido como un pilar fundamental a la hora de conocer las novedades del ecosistema Spring y sus alrededores, principalmente Java y otros lenguajes de la JVM (Kotlin, Scala, Groovy). En este post repasamos algunas de las principales novedades que nos trajo.

Tras el parón de dos años debido a la pandemia, volvió al Palacio de Congresos de Barcelona con más ímpetu que nunca. Más de 1200 asistentes, 50 conferencistas, workshops, stands corporativos, networking y, claro está, ping-pong y futbolín para amenizar las pausas.

Paradigma estuvo allí y en este post os dejamos un pequeño balance.

Microservicios y Spring, esas palabras mágicas

Hace años vivimos en un mundo de microservicios. Matt Raible, de Okta, nos habló de cómo construirlos con su aplicación JHipster de manera rápida y customizable, con una interfaz ligera que nos permite elegir qué usaremos para el backend, para el front, qué tipo de seguridad, cómo manejaremos las dependencias, qué tipo de BBDD, etc.

Luego se introdujo en la historia de Spring para llegar a la actual versión 5 (y su correspondiente Spring Boot 2.0), aparecidas en 2017. Una de sus novedades fue apostar por la reactividad, apoyada en el Project Reactor, permitiendo que las aplicaciones utilicen menos recursos y sean más escalables.

A partir de allí, dentro del equipo de Spring se desarrollaron proyectos como Spring WebFlux para permitir manejar una cantidad potencialmente apabullante de peticiones concurrentes de manera non-blocking, aprovechando la potencia de los modernos procesadores multi-núcleo sin bloquear hilos como la vieja API Servlet. Del lado del gateway esto significó un cambio desde Zuul hacia Spring Cloud Gateway. Por último, y para mencionar solo algunas de las ventajas del paradigma reactivo, este soporta protocolos más avanzados como RSocket y, gracias a desarrollos del proyecto Spring Cloud Stream, permite el manejo reactivo de mensajería con RabbitMQ y Kafka, entre otros.

Es importante enfatizar, dijo Raible, que si tus servicios no reciben un importante número de peticiones (más de 500 por segundo) quizás no sea conveniente cambiar desde Spring MVC a Spring WebFlux, debido a que la curva de aprendizaje es alta y la developer experience puede verse resentida.

Programación reactiva y clientes HTTP

Sobre clientes declarativos HTTP y programación reactiva también hablaron Olga Maciaszek-Sharma y Rossen Stoyanchev, dos relevantes contribuyentes del equipo Spring.

Comenzaron por la manera más verbosa y nativa de realizar una petición HTTP, con una clase cliente que construye la petición -con su body, sus cabeceras, su URI de endpoint- y la realiza mediante un RestTemplate inyectado. Esta manera no es declarativa y es muy poco reutilizable, además de confusa, puesto que cada método debe realizar varias acciones (armar la petición, llamar al endpoint).

@Override
public CustomerVerificationResult verify(CustomerApplication customerApplication) {
HttpHeaders headers = buildHeaders();
HttpEntity<CustomerApplication> request = new HttpEntity<>(customerApplication, headers);
return restTemplate.postForObject("/verify", request, CustomerVerificationResult.class);
}

private HttpHeaders buildHeaders() {
return buildHeaders(Collections.emptyMap());
}

private HttpHeaders buildHeaders(Map<String, String> headerValues) {
HttpHeaders headers = new HttpHeaders();
headers.set("X-Custom-Header", "test");
headers.setAll(headerValues);
return headers;
}

Luego mostraron las mejoras introducidas por Feign / OpenFeign (OF) como parte del stack de Netflix que pasó a la comunidad y en el cual Olga colaboró. Aquí tenemos ya soporte para varios tipos de clientes HTTP (Apache, Ok HTTP, etc.), anotaciones, métricas (Micrometer, que se recomienda de ahora en adelante para lo que anteriormente se utilizaba Sleuth) y facilidad de encoding/decoding (GSON, Jackson). Desde el proyecto Spring Cloud OpenFeign se han dedicado estos últimos años a proveer integración entre OF y Spring Boot con las ya conocidas anotaciones server-side de Spring Web MVC (@PostMapping, etc.), auto-configuración y soporte para LoadBalancer, CircuitBreaker y traceo. Este framework ha tenido y tiene gran difusión entre todos nosotros, ya que su curva de aprendizaje es muy baja para los usuarios habituales de Spring Web MVC.

Servidor:

@RestController
public class PersonVerificationController {

private final PersonVerificationService verificationService;

public PersonVerificationController(PersonVerificationService verificationService) {
this.verificationService = verificationService;
}

@PostMapping("/verify")
Mono<PersonVerificationResult> verify(@RequestBody Person person) {
return Mono.just(verificationService.verify(person));
}
}

Cliente:

@FeignClient("verification-service")
public interface VerificationServiceOFClient {

@PostMapping(path = "/verify")
CustomerVerificationResult verify(@RequestBody CustomerApplication customerApplication,
@RequestHeader("X-Custom-Header") String customHeader);

}

OF no necesita siquiera implementar la interfaz: Spring lo hace por nosotros, de manera transparente, simplemente gracias a la anotación y el application name del servicio de verificación registrado en Eureka.

Sin embargo, comenzaron a surgir problemas con OF. Si bien era desalentada, la posibilidad de usar las mismas anotaciones para el servidor y para el cliente (cómodo a la hora de desarrollar con “copy-paste”) se volvió especialmente problemática con algunas características de @RequestMapping que solo tienen sentido del lado del servidor, como el uso de wildcards o la posibilidad de atender todos los métodos HTTP de un mismo path. Había también desfases de mantenimiento entre Feign (third-party) y OpenFeign (comunidad). Por último, el carácter blocking del framework no se adaptaba a los objetivos a futuro de Spring.

Manteniendo su camino el proyecto Spring Cloud OpenFeign, se decidió que la solución a estos problemas y el soporte para los escenarios non-blocking debía ser provisto al nivel base del Spring Framework 6.0. Así, crearon una nueva anotación @HttpExchange pensada para el lado del cliente (si bien no está prohibida su implementación en el controlador del servidor), con una selección de los parámetros ya conocidos.

public interface VerificationService {

@PostExchange(url = "/verify")
CustomerVerificationResult verify(@RequestBody CustomerApplication customerApplication);

}

Existen también anotaciones “hijas” para cada tipo de método HTTP (en este caso, POST). En el futuro está planeado implementar estos clientes no solo para HTTP, sino también para RSocket (ya disponible desde el Milestone 4) y GraphQL.

Novedades en Spring 6

Nos adentramos en el Spring Framework 6. Saldrá a la luz en GA en noviembre de 2022, y en el Spring IO pudimos conocer de boca de su Project Lead, Juergen Hoeller, qué nos depara el futuro cercano de este ecosistema.

Desde 2017 está entre nosotros Spring Framework 5. Actualmente, en su versión final 5.3.x, está también ligada a Spring Boot 2 (actualmente 2.7.x). Esta versión ha brindado soporte para las LTS de Java 8, 11 y 17 (la actual), y se espera que llegue hasta la JDK 19. Se basa en Java EE (y su sucesor, Jakarta EE), en el namespace javax, así como en la JVM clásica. Spring 5 ha estado pensado tanto para programación imperativa como reactiva. Si bien desde sus inicios Spring había sido pensado complementariamente a Java EE y su despliegue en un servidor de aplicaciones, la llegada de Spring Boot permitió que por ejemplo una aplicación WebFlux pueda desplegarse en servidores como Netty que no son contenedores de Servlet.

¿Qué nos espera, entonces, para Spring Framework 6? Pues estará apuntada a Java 17 y superiores; en cuanto a Jakarta EE soportará la versión 9 (el namespace jakarta). Como hemos dicho, la GA aparecerá en noviembre de este año, es decir, a menos de un año de la salida de la siguiente LTS de Java (JDK 21, prevista para septiembre de 2023): esta será la versión que los desarrolladores tendremos que considerar de cara a los próximos años trabajando con Spring.

Uno de los puntos clave en este sentido, ligado al futuro de Java, tiene que ver con él (ya en boca de muchos) “Project Loom”, que busca implementar una solución de concurrencia más ligera a partir de threads virtuales, manejados en pools. La ejecución de tareas que antes requerían un thread físico cada una (acoplada al sistema operativo) podrá realizarse en estos threads virtuales (es decir, en el runtime de Java). La promesa, si todo sale bien, es que los threads serán “más baratos”, lo que desatará un fenomenal aumento de la libertad para programar aplicaciones concurrentes complejas. Os animo a trastear con las Early Access Releases de JDK 19. Spring Framework 6, en línea con este proyecto, incorporará el procesamiento “Ahead-Of-Time” que permitirá cargar ciertas características del contexto de aplicación previamente, para aligerar la infraestructura que carga cada empaquetado. Se reducirá el tiempo de arranque, a costa de cargar más el build. Está relacionado con otro proyecto de Java, el Project Leyden, que apunta a introducir “imágenes estáticas”.

Por último, Spring Framework 6 se está planteando soportar los “módulos” de Java, una novedad introducida en el JDK 9 que nunca ha tenido mucha aceptación en la comunidad. De momento, Spring 5 solo admite _automatic modules, _es decir, los que se crean automáticamente con su module-name y cuyo fin original fue mantener la retrocompatibilidad con JDK anteriores.

¡Por fin ha regresado el Spring Authorization Server!

En el mundo de Spring Security tenemos la gran novedad de que volveremos a contar con un Authorization Server, tras el deprecado hace unos años del proyecto Spring Security OAuth. Desde entonces, para realizar la autorización debíamos recurrir a APIs de terceros, como Keycloak ó Okta.

Pues ya se encuentra en su versión 0.3.0, listo para producción, el Spring Authorization Server. Provee soporte para OAuth 2.1, lo cual significa que no soporta los grant type “implicit” ni “password”; y para OpenID Connect (OIDC) 1.0. En la página oficial contamos con un “Getting started” muy práctico para entender cómo configurar desde cero un proyecto con esta securización, con sus filtros, su definición de usuarios y roles, su firmado de tokens y demás customizaciones encadenadas dentro de métodos que registran @Bean como nos tiene acostumbrados Spring.

En el workshop de Andreas Falk (Novatec), entre otras charlas que mencionaron el tema, pudimos trastear con un ejercicio que implementó un cliente, dos servidores de recursos y un servidor de autorización con el nuevo Spring Authorization Server. Aquí tenéis el código en Github.

¿Y qué hay con Java?

Relacionado con todo esto, pudimos conocer y recapitular algunas de las últimas novedades de Java introducidas desde la anterior LTS (11), de la mano del Developer Advocate, Billy Korando (Oracle). Solo las mencionaremos brevemente:

• Desde la versión 15, Java admite text blocks, esto es, la posibilidad de redactar un bloque de texto con sus saltos de línea y sus caracteres especiales sin necesidad de escaparlos, mediante la inclusión de triple comilla doble (“””) al inicio y al final del bloque.
• Desde Java 14 incorporamos también nuevas funcionalidades de switch, como la posibilidad de aligerar un bloque grande de opciones mediante el operador de flecha (→) o bien la de “devolver” un valor en caso de coincidir con la expresión evaluada.
• Desde Java 16, instanceof se puede usar para pattern matching y declarar una variable local en el método o el bloque de código que lo precise, aligerando la operativa.
• Desde Java 17 tenemos las sealed classes, que nos permiten explícitamente habilitar qué otras clases pueden heredar a la nuestra.
• Los records, introducidos en Java 16, apuntan a eliminar el boilerplate code (getters/setters, constructores) para clases que representen datos. Es algo ya conocido por usuarios de otros lenguajes de programación funcional.
• Desde Java 18 tenemos el jwebserver, un simple servidor web con finalidad didáctica, que atiende en localhost:8000. Era algo muy pedido por la comunidad académica.

Conclusiones

Tras dos años sin encontrarnos, desde la comunidad Spring estábamos muy entusiasmados por este evento y nos ha dejado más que satisfechos. Tanto a los veteranos como a los novatos nos ha permitido conocer de primera mano el estado actual del ecosistema, sus debates, sus opiniones encontradas y sus acuerdos. Es de esperar que en próximas ediciones tengamos más detalles sobre implementaciones en Spring de protocolos como gRPC ó RSocket, o que podamos conversar sobre las primeras experiencias de la comunidad desarrollando con Spring para GraphQL, que ya ha sido lanzado en su versión 1.0.0.

Como recomendación, quisiera dejaros el mensaje de que probéis las nuevas versiones de los frameworks y las librerías aún en su estado “embrionario”, a pesar de que ¿a quién no le han dicho en épocas de estudiante que mejor apuntar a la versión con más descargas en Maven Repository? El poder trastear con código que aún no ha salido a la luz abiertamente os generará una emoción muy especial.

Por último, os animo a apuntaros al próximo Spring IO, que en 2023 celebrará su décima edición. Hasta entonces, podéis escuchar el podcast de Josh Long en el cual conversó con su fundador y persistente activista del ecosistema, Sergi Almar, tras su paso por Barcelona. También echad un vistazo a su página en YouTube, donde día a día van subiendo las conferencias de este año, además de las de ediciones anteriores.