Que esperar/aprender de Java en 2020

Inicio el año con seis predicciones para Java en 2020. A diferencia del difunto Walter Mercado la mayoría no son resultado de ver las estrellas. Más bien son el resultado de patrones que observé en 2019 en la industria, clientes, conferencias y creo que se consolidaran en este año.

1. Java 11 finalmente se masificara

Uno de los mayores problemas con la aparición de Java 9 fue la introducción de JPMS o «Java modules». Diferente de otras versiones de Java esto creó un mar de bugs porque entre otras cosas ocultó el paquete sun.misc.unsafe utilizado por varias bibliotecas importantes.

Aunque pareciera poco importante que una biblioteca no tenga acceso a un paquete o a una característica, impacta en cascada a los usuarios de la biblioteca, que eventualmente impacta a los frameworks, que eventualmente impacta a los runtimes, que eventualmente impactan a los «developers callejeros» que utilizan estos frameworks. Toda una pesadilla.

En 2019 observé sin embargo que los grandes runtimes Java empezaron a dar soporte oficial a Java 11 ya sea como primicia o como consolidación de lo presentado durante 2018, algunos de los más importantes de los que uso en mi día a día:

1. Tomcat
2. Jetty
3. JavaFX
4. Spring Boot
5. Wildfly
6. Payara (ex. Glassfish)
7. Open Liberty

Probablemente el ultimo en unirse al grupo sera WebLogic que ya tiene una versión beta con Java 11, más vale tarde que nunca :).

2. La pelea en el Java moderno se dará en el campo AOT

Uno de los mayores deseos de las bibliotecas Java hoy en día es declararse «compatible con GraalVM AOT» lo que significa que la biblioteca es compatible con la generación de binarios nativos para Linux (y Mac).

Aunque los binarios AOT son relativamente más lentos que la ejecución de bytecode sobre una JVM con JIT, en el mundo de los microservicios y sobre todo en serverless suele quedar en segundo plano frente a la velocidad de «cold start».

En esta linea Quarkus, Helidon y Micronaut lideran indiscutiblemente. Curiosamente 2 de estos 3 son compatibles con MicroProfile, ¿quien lo diría hace unos años?.

En Latinoamérica probablemente seguirá la tendencia de Spring, pero en el resto del mundo creo que su dominio finalmente se ve amenazado. Sin contar que la recompra por parte de VMWare puede traer efectos a mediano plazo sobre Spring.

3. Kotlin pasara 2020 sin brillar en el espacio backend JVM

Uno de los problemas fundamentales de Kotlin en el backend es su relativa dependencia de IntelliJ IDEA, lo cual no es un problema en desarrollo móvil, pero es un problema en desarrollo backend.

El desarrollador backend Java tradicionalmente:

1. Trabaja en una institución financiera, startup consolidada o empresa de telecomunicaciones
2. Soporta proyectos desde Java 6 hasta Java 11
3. Pertenece a grupos ligeramente grandes de desarrolladores (+10 devs)
4. Despliega sus aplicaciones en un applicaton server con soporte comercial -e.g. WebLogic, WebSphere, TomEE-.
5. Utiliza algun IDE basado en NetBeans o Eclipse

Aunque es viable programar utilizando IntelliJ IDEA community en fatjars y microservicios, lo cierto es que se necesita IntelliJ IDEA completo para interactuar con application servers desde el IDE, lo cual limita el nivel de adopción que puede tener el lenguaje en entornos tradicionales.

Dificilmente un CTO va a decidir dar el salto de IDEs gratuitos y de calidad como NetBeans o Eclipse hacia IntelliJ donde cada copia arranca en aprox. $500. En esta linea, el soporte para Kotlin en NetBeans está muerto y el soporte en Eclipse no es el mejor.

4. JakartaEE renacerá o morirá

Luego del tumultoso traspaso de Java EE desde Oracle hasta la fundación Eclipse, se estan resolviendo finalmente las novelas alrededor del proceso, entre las más importantes:

• La imposibilidad de utilizar el paquéte javax.*
• La propiedad intelectual sobre la documentación
• La propiedad intelectual sobre estandares como CDI
• El nuevo proceso de certificación y TCK

Por lo que he leído en las listas, la tendencia en JakartaEE 9 sera remover APIs poco utilizadas en Java EE 8, pero el veredicto final si esto sera sostenible a largo plazo sera la comunidad.

Uno de los primeros pasos en la linea correcta fue el contar con implementaciónes compatibles con JakartaEE 8 lo que demuestra la solidez del proceso, pero 2020 sera crucial para la supervivencia de los estandares empresariales en Java. Creo que Eclipse ha hecho todo lo que está en su poder para involucrar fabricantes, pero sobre todo a la comunidad.

Como «lobo viejo» que cree en los estandares y la independencia de proveedores, espero que esto sea exitoso, a nivel personal lo que me ha mantenido en Java todo este tiempo no es el lenguaje, es el ecosistema y la independencia de proveedor.

5. Java 14 sera para muchos la primera beta de Java 17

Con cada nueva versión de Java, la mayoría de características nuevas suelen encajar en 3 grandes categorías:

• Mejoras al lenguaje de programación
• Mejoras a la JVM (entorno de ejecución)
• Mejoras a las herramientas del Java Developer Kit

Por alguna razón las mejoras que suelen interesar a más desarrolladores siempre son las mejoras en el lenguaje y Java 14 sera un lanzamiento prometedor en esta categoría, el cual incluye algunas de las novedades más esperadas en el lenguaje:

• Mejoras a los mensajes en caso de NullPointerException
• Records (aka clases sin get y set)
• Switch expressions
• Pattern Matching
• Text blocks

¿Porqué la beta de Java 17?. De acuerdo al nuevo esquema de lanzamientos predecibles de Java, el siguiente LTS de Java es Java 17, donde la mayoría de personas se suben al vagón de la innovación.

6. Finalmente se estabilizara la gran batalla de las distros Java

Luego de que Oracle decidiera cambiar la licencia de su Java Virtual Machine, vimos el nacimiento de la gran batalla de las distros Java.

TL;DR: Java sigue siendo libre y gratis. Casi todas las distros se basan en código del proyecto OpenJDK.

Mi predicción es que algunas distros moriran por falta de interés o masa critica, pero seguramente las siguientes serán las sobrevivientes:

1. AdoptOpenJDK: Fue la que pegó primero, presentó un website más bonito y es la preferida del sector hipster por no depender de un único proveedor.
2. Oracle HotSpot: Porqué es obligatoria para cualquier cliente con productos Oracle
3. SAP JVM: Porqué es obligatoria para cualquier cliente con productos de SAP
4. OpenJDK de RedHat: Porqué es obligatoria para cualquier cliente con soporte comercial de Red Hat
5. OpenJDK de tu distro Linux favorita: Si no usas Red Hat, probablemente usas una compilación propia de la distro que vivira mientras viva la distro. Son demasiados links para cada distro Linux «raiz».
6. Azul Zing: Encontró su nicho en alianzas con proveedores importantes como Payara o Microsoft. Además de la experiencia de Azul Systems en la creación de JVMs.
7. OpenJ9: Porqué es la JVM oficial de IBM.

No dudo en que alguien más decidirá sacar su propia distro de OpenJDK, pero como bien ha demostrado Linux, pueden existir 100 o más distros pelotudas pero todas al final derivan de 2 o 3 proyectos realmente importantes.