Continuando con una tradición que he ejecutado en 2020 y 2021, iniciare el año con mis predicciones acerca del ecosistema de la Java Virtual Machine. He visto que los post de años anteriores fueron bastante certeros entonces espero que este año no sea la excepción.
Spring impulsara a GraalVM Native
Como lo mencioné el año pasado, Spring presentó en 2021 su versión enfocada en compilación AOT (de la cual he hablado a detalle en un vídeo). Aunque Quarkus, Micronaut y Helidon ya destacaban en el frente AOT, debemos recordar que Spring sigue al día de hoy como el #1 en lo que respecta a frameworks Java.
El hecho que Spring impulse a GraalVM Native también debiera acelerar la aparición de bibliotecas reflectionless para que sean compatibles de forma «fácil» con la compilación nativa proveida por GraalVM Native, esto es genial para el ecosistema ya que no todos usamos Spring pero nos beneficiamos :).
Si aún no han experimentado con GraalVM Native, seguramente lo haran con Spring.
El fiasco de log4j se convertirá en FUD a Java
A menos que vivan bajo una piedra, si viven dentro del ecosistema de Java ya saben que hubo un gran agujero de seguridad en la biblioteca log4j, la cual permitió entre otras cosas ejecución remota de código, obteniendo así la mayor calificación de riesgo.
No fueron pocos los medios que reportaron su descubrimiento, incluso medios no enfocados en programación. De este episodio saco dos cosas:
- Me parece impresionante como la gente declara a Java muerto, cuando al mismo tiempo un error en una biblioteca afectó a medio mundo. Incluyendo lugares donde uno no lo imagina como en el hardware de Cisco, básicamente la carretera de Internet.
- Este error pudo pasar (y ya pasó) en otros ecosistemas, pero por lo extendido que está el uso de Java ha servido para propagar FUD al respecto de la plataforma y el lenguaje, sorprendente si se considera que el error fue parchado en tiempo record.
Debo resaltar que aunque el parche fue lanzado de forma inmediata, el origen de la mala reputación van a ser aquellos despliegues desatendidos y sin actualizaciones, aplicaciones con malas prácticas y poco control de dependencias. Una pena pero es lo que hay. Esto también lo resaltó el director de la NSA, pero es más fácil decir «me hackearon por usar Java vamonos a Elixir».
El ecosistema DevOps Java girara alrededor de Testcontainers, Docker y extensiones basadas en JUnit
Hemos recorrido un largo camino y sin miedo a equivocarme Java (junto a Maven) tienen uno de los mejores ecosistemas para flujos de trabajo DevOps.
Muchos de los conceptos inventados por JUnit (y TestNG) ahora son ubicuos en varios ecosistemas de software. Si han estado lo suficiente en Java probablemente han visto la siguiente evolución
- Cactus
- Embedded EJB
- Arquillian (Mi favorito)
Arquillian a mi punto de vista fue el último gran intento de estandarizar las practicas de integration test en Java Empresarial. Aunque sigue bastante vivo, he empezado a notar que cada framework también incluye su propio entorno de ejecución de tests basado en extensiones JUnit, lo vemos ya en:
¿Porqué JUnit?. JUnit es un estandar de facto para la creación de tests en Java y lo más importante, casi todos los entornos DevOps o CI/CD -e.g. Gihub, Gitlab, CircleCI, Jenkins- utilizan el formato de reportes de JUnit para flujos de trabajo basados en Java.
Uno de los temas pendientes en todos estos frameworks y bibliotecas siempre han sido las bases de datos, a principios de la decada pasada se popularizó el uso de bases de datos en memoria como H2 o Apache Derby, al punto de que en JakartaEE aún es requerido que se incluya una base de datos en memoria en los servidores de aplicaciones.
Aunque en principio los tests sobre H2/Derby son los suficientemente buenos para software creado con JPA, los problemas empiezan cuando queremos validar particularidades de cada base de datos, por ejemplo:
- SQL Nativo
- Índices (o la falta de)
- Diferencias entre mayúsculas y minusculas
- Comportamiento de pool de conexiones
- Reactividad y drivers reactivos (o pseudo-reactivos)
Esto ha impulsado la adopción de Testcontainers (mi biblioteca favorita de 2021), que a grandes rasgos nos permite (de nuevo mediante JUnit) ejecutar contenedores Docker para desplegar o complementar nuestra aplicación, aprovisionar bases de datos de pruebas, o lanzar cualquier otro servicio que esté disponible como contenedor Docker.
Esta revolución a mi parecer inició con Arquillian Cube, pero Testcontainers ejecutó de forma más simple y funciona en cualquier entorno, no solo entornos basados en CDI.
Se detendrá la proliferación de Java Virtual Machines
Con el lanzamiento de Java 17, Oracle cambió nuevamente la licencia de SU JVM (aka HotSpot) la que de acuerdo a estadísticas propias, es la que la mayoría de la gente sigue usando.
Aunque siempre vale la pena leer la letra pequeña, lo cierto es que Oracle brinda más opciones para utilizar HotSpot de forma gratuita y para mucha gente esto es suficientemente bueno como para ya no plantearse una alternativa, siendo así deberíamos ver la muerte de algunas «distros Java».
¿No sabias que existen otras distros Java?, siempre es buena idea consultar la tabla de foojay, a mi parecer la más completa
MicroProfile se alineara más a CNCF
La «otra» gran alternativa a Spring es MicroProfile, aunque su adopción seguramente es menor, ha sido fuertemente impulsado por la popularidad de Quarkus.
Dicho esto, recordemos que el paso del espacio Cloud Native lo marca la Cloud Native Computing Foundation, y aunque existen esfuerzos para tener un punto central Cloud Native en el ecosistemas de Java, el ecosistema CNCF ya es lo suficientemente grande y maduro como para aceptar que las herramientas Java se tienen que alinear si quieren sobrevivir en un mundo cada vez más serverless y Kubernetico.
Esto la verdad no es necesariamente malo y en esta línea vemos como la apuesta de Jakarta EE es cada vez más Cloud Native y cada vez menos a lo que estábamos acostumbrados (app servers tradicionales, instalaciones on premise).
Por cierto no se pierdan mi curso gratuito de MicroProfile, directamente en el sitio del proyecto :).
Las «emociones» de la JVM se centraran en Loom, Panama y un poco menos en Valhalla
El cambio a Java modular fue por decirlo de una forma amable «doloroso», pero los que seguimos el carrito de lanzamientos hemos visto como las innovaciones llegan de forma más rápida a Java.
Luego de superar la velocidad de lanzamiento, migraciones de Java 8 a 11 y de 11 a 17 en algunos casos, lo que nos queda a los desarrolladores Java es aprovechar este flujo constante de actualizaciones, en esta línea veo que lo más emocionante viene de tres frentes:
- Los virtual threads con Project Loom
- La ejecución nativa de código vía Project Panama
- La reducción y simplificación de memoria vía Project Valhalla
Project Amber (mejoras en el lenguaje) ha presentado bastantes innovaciones y nos na tenido «tranquilos», pero lo realmente impresionante serán las posibles mejoras en escalabilidad proveidas por estos tres proyectos, desde mi trinchera les deseo muchos éxitos a los arquitectos de Java
Bienvenido 2022
Si llegaron hasta acá les deseo un 2022 lleno de Java, no tan lleno de pausas en el Heap y no olviden que estoy en muchas redes sociales:
Mozilla/5.0 (iPhone; CPU iPhone OS 14_8_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.2 Mobile/15E148 Safari/604.1
Gracias, tienes un nuevo seguidor, me gusta lo que leo y lo entiendo, asi que sigue asi y felicidades por tu trabajo.
The Incutio XML-RPC PHP Library -- WordPress/6.1.1
[…] esta tradición en 2020, que luego tuvo buena recepción en 2021 y 2022, los dejare como jueces del resultado final pero a mi parecer las predicciones han sido bastante […]