Llega Java 21, pero ….
Durante este fin de semana, vi azorado la cantidad de publicaciones sobre Java 21, sus nuevas (abundantes) features, sus preliminares, etc. algunas muy interesantes y necesarias, otras las vi como una innecesaria forma de captación y ponerse a la par de otros lenguajes que le han quitado un pedacito del marketshare, por ejemplo (https://openjdk.org/jeps/445).
Pero lo que me sigue llamando la atención es que de las versiones LTS disponibles Java 8 u 11 siguen siendo el standard de la industria por sobre la 17. Lo cual me trajo recuerdos de cuando era Desarrollador en Powerbuilder, que a pesar de ya andaba por la versión 12.5, las más usadas eran la 6.5 (Primera versión de Sybase) o la 10.5.
Entonces la pregunta es que hace que nos permanezcamos con una determinada versión, cuales son los motivos que incentiva a migrar a una nueva?
Repasemos un poco las novedades (Features para los amigos) de cada versión y veamos si existen los motivos necesarios para migrar
Features de cada versión
Java 8:
1. Expresiones Lambda
2. Streams API
3. Método predeterminado en interfaz
4. Funciones de referencia
5. Nueva API de fecha y hora
6. Anotaciones de tipo de variable
7. Mejoras en la seguridad de Java
Java 9:
1. Módulos de Java (Java Platform Module System)
2. Colecciones inmutables
3. Factoría de colecciones
4. Proceso de recolección de basura paralelo mejorado
5. Mejoras en el rendimiento de Java
Java 10:
1. Inferencia de tipo de variable local
2. APIs de mejora del rendimiento
3. Mejoras en la seguridad de Java
4. Mejoras en el rendimiento de Java
Java 11:
1. Var para parámetros lambda
2. API HTTP Client estándar
3. Soporte para Unicode 10.0
4. Garbage Collector mejorado (Epsilon)
5. Mejoras en el rendimiento de Java
Java 12:
1. Switch de expresiones
2. Proceso de recolección de basura en paralelo mejorado
3. Rendimiento mejorado de JVM
4. Mejoras en la seguridad de Java
Java 13:
1. Text Blocks
2. Actualización de Garbage Collector
3. Cambios en las expresiones lambda
4. Mejoras en la seguridad de Java
Java 14:
1. Records
2. Patrones de instanciaof
3. Mejoras en la seguridad de Java
4. Actualización de Garbage Collector
Java 15:
1. Patrones de coincidencia
2. Text Blocks mejorado
3. Seguridad de Java mejorada
4. Actualización de Garbage Collector
Java 16:
1. Registros mejorados
2. Patrones de coincidencia mejorados
3. Mejoras en la seguridad de Java
4. Actualización de Garbage Collector
Java 17:
1. Nuevo tipo de archivo en Java
2. Nuevas API de seguridad de criptografía
3. Nuevo sistema de memoria nativa
4. Mejoras en la seguridad de Java
Java 18
1. UTF8 por Defecto
2. Simple Web Server
3. API para Vector
4. Resolucion de Direcciones de Internet SPI
Java 19
1. Patrones para Record
2. Hilos Virtuales (Loom Project)
3. Linux/RISC-V Port
Java 20
1. Patrones para Record
2. Hilos Virtuales (Loom Project)
3. API para Vector
4. Funciones externas y Api de Memoria
Hace mucho tiempo leí Freakonomics por Steven D. Levitt y Stephen J. Dubner, realmente me voló la cabeza para entender cómo llevar adelante los cambios, principalmente como motivar a que ellos ocurran. Según su enfoque, la motivación puede ser entendida como la búsqueda de maximizar las recompensas y minimizar los costos. Las personas toman decisiones basadas en una evaluación subjetiva de los beneficios y las consecuencias esperadas.
Entendiendo esto exploremos las motivaciones para quedarnos con ciertas versiones de Java que ya tienen sus años
Estabilidad: Java 8 ha estado disponible durante mucho tiempo, esto ha permitido a las empresas y organizaciones adaptar sus sistemas y aplicaciones a esta versión. Esto ha llevado a una amplia adopción y a la confianza en la estabilidad y confiabilidad de Java 8
Retrocompatibilidad: Java es conocido por su enfoque en la retrocompatibilidad, las aplicaciones desarrolladas en versiones anteriores de Java suelen funcionar sin problemas en Java 8. Esto ha facilitado la transición y la actualización para muchos proyectos y organizaciones.
Frameworks y librerías: Java cuenta con un ecosistema muy amplio y maduro, con numerosas librerías y frameworks disponibles que son compatibles con Java 8. Muchas de estas librerías aún no han migrado completamente a versiones más recientes de Java, lo que ha contribuido a la continuidad del uso de Java 8.
Features realmente útiles: Java 8 y Java 11 introducen una serie de cambios que realmente eran necesarias en ese momentos, no solo para mantener al lenguaje competitivo frente a otros, si no también siendo mejoras a la performance y la productividad. Por ejemplo, expresiones lambda y la API de Streams de Java 8, que permiten un código más conciso y legible, y facilitan la programación funcional y el procesamiento de colecciones de datos. En Java 11 el sistema de módulos, permite modularizar las aplicaciones y el JDK en componentes msás pequeños y bien definidos. Esto ayuda a mejorar la encapsulación, la reutilización y el mantenimiento del código, además la API HTTP Client estándar, es más moderna y flexible en comparación con la antigua HttpURLConnection. Proporciona características avanzadas como manejo de solicitudes asíncronas, complementos y soporte nativo para HTTP/2.
Ahora Java 17 aunque ya tiene casi 2 años, todavía no alcanza a sus predecesores en cuanto a uso posicionándose como el standard del mercado, contando con features muy buenas, pero que todavía no son motivación suficiente para el cambio.
Las “clases selladas” (sealed classes): permiten controlar qué clases pueden ser subclases de una clase dada. Esto proporciona una mayor seguridad y control sobre la herencia de clases.
Java Records: (esta la espere años) simplifica la creación de clases utilizadas para almacenar datos (como modelos de datos o estructuras de información). Un Java Record es una clase inmutable y de solo datos que proporciona automáticamente la implementación de métodos comunes, como los métodos equals(), hashCode() y toString(), basados en los campos declarados en la clase. Pero existe lombok que ya este arraigado en la comunidad, esto propicia que se solvente la ausencia de Java Records en los otros LTS, usando esta librería, aunque siendo puristas no es lo mismo, pero se parece.
Conclusión:
En lo personal soy un feliz usuario de Java 17 LTS, pase casi directo de la 8, con una breve escala en la 11. Porque, como comenté lo de Powerbuilder, ya he vivido una transición de empresas (powersoft-sybase-sap) y todos los altibajos entre versiones hasta que se logra una confiabilidad plena, no por el producto en si, sino por ese cambio de propietarios y responsables de la tecnología, además los features hasta la 11, para lo que yo venía realizando, no me cambian el panorama, ni suponen una mejora en mi productividad, hoy con la 17 ya con todos los features asentados de las versiones anteriores, si me motivo al cambio.
