Tendencias de Java en 2022: JDK 18 y 19, Project Loom y Data mesh

Bueno, el 2022 ha comenzado. Mientras la mayoría de la gente todavía está de vacaciones de Año Nuevo con champán y Olivier, nosotros hablaremos de las tendencias en el mundo de Java. Quizás esto le ayude a analizar su carrera, aprender una nueva tecnología o elaborar un plan de desarrollo para el próximo año. El profesor y especialista en lenguaje Java Andrey Rodionov, así como el arquitecto de soluciones de EPAM y jefe del comité de programa de Devoxx Ucrania, Oleg Tsal-Tsalko, hablaron sobre lo que le espera a Java en 2022 y en el futuro cercano.

¿Cuáles son las perspectivas para Java en 2022?

Este año esperamos el lanzamiento de las próximas dos versiones: JDK 18 (en marzo) y JDK 19 (en septiembre). Lo potencialmente interesante para la mayoría de los desarrolladores de Java en JDK 18 puede ser:

• Servidor web simple incorporado, sin soporte para un contenedor de servlets, que se puede utilizar para realizar pruebas y prototipos rápidos, similar a mini servidores web similares en Python, Ruby, PHP.
• La combinación de patrones continúa mejorando.

En cuanto a JDK 19, ya existe una versión de acceso anticipado, pero aún no hay una lista oficial de lo que se planea incluir en ella. Me gustaría creer que JDK 19 incluirá al menos el primer prototipo estable de Project Loom, para el cual han aparecido recientemente especificaciones preliminares y cuya última versión se basa en JDK 19. Hablaremos de Project Loom con más detalle a continuación.

¿Para qué áreas Java sigue siendo la única solución y dónde es preferible?

Andréi Rodionov:

Afortunadamente, no podemos decir que no existe una alternativa a Java para ninguna de las áreas, pero podemos hablar de Java como una especie de medio dorado para desarrollar aplicaciones empresariales, backends y microservicios. También vale la pena señalar el número cada vez mayor de distribuciones JDK diferentes de diferentes proveedores (excepto Oracle): Amazon, Microsoft, Alibaba, Red Hat, Bellsoft (fundada por personas del Centro de Desarrollo de Oracle en San Petersburgo) y otros. El conjunto completo de distribuciones está disponible aquí . Siempre hay alternativas, pero Java encuentra su mayor uso en el backend del desarrollo empresarial. La mayoría de las grandes empresas eligen Java para sus sistemas grandes y complejos. Las razones son las mismas: la cantidad de desarrolladores y experiencia en el mercado, un ecosistema enorme y una potente plataforma JVM.

¿Cuáles son las perspectivas para otros lenguajes jvm, en particular Kotlin, en comparación con Java?

Andréi Rodionov:

Para comprender qué lenguajes JVM son populares, simplemente abra la documentación de Spring, Micronaut, Vert.x y vea en qué idiomas se dan los ejemplos de código: Java y Kotlin serán comunes. No se puede decir que haya una transición masiva de proyectos a Kotlin, pero su popularidad para el backend sigue creciendo y muchos frameworks están intentando incluirlo en su ecosistema. En cuanto a Scala, se están lanzando nuevas versiones y se utiliza activamente para ML, procesamiento de datos y donde el paradigma de programación funcional es más conveniente.

Oleg Tsal-Tsalko:

Otros lenguajes JVM son bastante atractivos y hoy en día es bastante normal que un proyecto utilice varios lenguajes de programación. Me parece que las razones por las que los lenguajes JVM novedosos no pueden desplazar a Java son las siguientes:

• No son tan geniales como para que todo el mundo los acepte y los cambie.
• Se utilizan en el mismo segmento que Java.
• Java poco a poco toma lo mejor de otros lenguajes y va mejorando.

¿Habrá una caída en la calidad de Java debido a intervalos de lanzamiento más cortos?

Oleg Tsal-Tsalko:

Creo que no. Al menos ahora puedo identificar cosas más positivas en los lanzamientos frecuentes. Vemos que aparecen nuevas funciones interesantes con mucha más frecuencia. Ahora no tienes que esperar 5 años para que aparezca algo nuevo en el idioma. Por supuesto, ahora no deberías esperar lanzamientos tan grandiosos como Java 8, porque las funciones ahora aparecen en pequeñas iteraciones.

¿Hay características en las nuevas versiones de Java que sean especialmente importantes para los desarrolladores?

Oleg Tsal-Tsalko:

Las versiones recientes de Java han introducido varias características interesantes, como coincidencia de patrones, clases selladas y registros. Recomendaría mirar sus capacidades. Por supuesto, las características más serias y esperadas están planeadas dentro de Project Loom y Project Valhalla, pero creo que las características dentro de estos proyectos también se lanzarán gradualmente.

Marco de primavera: ¿seguirá ampliando su ecosistema para satisfacer diversas necesidades?

Andréi Rodionov:

En cuanto a Spring Framework, su desarrollo se ha centrado en admitir varias características de Spring Cloud y la capacidad de compilar Spring Boot en binarios nativos: el proyecto Spring Native, que se planea que forme parte de Spring Core en el futuro. En este sentido, Spring quedó por detrás de Micronaut y Quarkus debido al uso activo de la reflexión y la generación dinámica de código. Respecto a Spring Framework 6, te aconsejo que veas el informe Spring 6 y más allá ¿Qué hay de nuevo en Spring Framework 6? de la conferencia Joker (de Oleg Dokuka y Alexey Nesterov). Los clave son la transición a JDK 17, el abandono de la configuración XML y Autowire a través de configuradores, un mayor desarrollo del soporte de Kotlin y el proyecto Spring Fu.

Oleg Tsal-Tsalko:

Spring, como el FW Java más popular hoy en día, no quiere ceder la palma. Estoy seguro de que el equipo de desarrollo pondrá sus mejores esfuerzos en el desarrollo de Spring. La primavera llena cada vez más nichos. Por ejemplo, Spring ha hecho mucho en el área de Reactive Streams/Programación reactiva con su Project Reactor. Ahora están promocionando el protocolo RSoket, que también parece prometedor.

Cuéntanos sobre el proyecto Loom: ¿para qué sirve, qué problemas resuelve?

Andréi Rodionov:

Project Loom es probablemente la innovación más interesante, que podría convertirse en un nuevo cambio tectónico para toda la plataforma JVM y todos los lenguajes sobre la JVM. Es posible que Project Loom no afecte tanto a los desarrolladores comunes, pero definitivamente afectará a todo el ecosistema, bibliotecas, marcos y otros lenguajes JVM que utilizan subprocesos múltiples. Project Loom introduce una nueva abstracción de subprocesos: subprocesos virtuales (análogos a las corrutinas). Si anteriormente un subproceso de Java estaba directamente vinculado a un subproceso del sistema operativo (SO), y la creación de un nuevo subproceso en Java conducía a la creación de un nuevo subproceso del sistema operativo, entonces con los subprocesos virtuales esta relación uno a uno se rompe. Al crear un nuevo subproceso virtual, no se creará un nuevo subproceso del sistema operativo y uno de los llamados subprocesos portadores (una especie de análogo de un grupo de subprocesos del sistema operativo) se reutilizará para realizar cálculos directos. Por lo tanto, se pueden ejecutar varios subprocesos virtuales sobre un subproceso del sistema operativo. Para tareas informáticas, este modelo de subprocesos virtuales no ofrece ninguna ventaja y, más bien, ralentiza la velocidad de los cálculos, pero para operaciones de bloqueo, como procesar solicitudes HTTP, esperar respuestas de la base de datos o de microservicios, este modelo será un ventaja significativa. El hecho es que con el modelo de subprocesos actual, bloquear/esperar un subproceso de Java conducía a subprocesos del sistema operativo inactivos; esto era un desperdicio de recursos y requería la creación de más subprocesos del sistema operativo. En el modelo de subproceso virtual, bloquear/esperar un subproceso virtual hará que se libere el subproceso portador sobre el cual se estaba ejecutando el subproceso virtual y se ejecute otro subproceso virtual en él. De esta manera, los subprocesos del sistema operativo se utilizarán de manera más óptima y se necesitarán menos para realizar tareas similares. En consecuencia, los fabricantes de bibliotecas, marcos y lenguajes JVM deberán adaptar su código a subprocesos virtuales. Por lo tanto, se avecina una gran reescritura :) Además del modelo de subprocesos virtuales, también está previsto introducir una nueva API para simplificar la orquestación de subprocesos: la llamada concurrencia estructurada. Ahora, por ejemplo, la concurrencia estructurada se utiliza activamente en las corrutinas de Kotlin y Scala ZIO. Desafortunadamente, aún se desconocen la versión JDK e incluso el año de lanzamiento de Project Loom. Cuando se le pregunta sobre la fecha de lanzamiento, el arquitecto jefe de la plataforma Java, Brian Goetz, responde con una frase filosófica: “Estará listo cuando esté listo”. Por lo tanto, estamos esperando y podemos probar versiones experimentales de Project Loom .

Oleg Tsal-Tsalko:

Loom es un gran proyecto general, dentro del cual el equipo de OpenJDK y Oracle está trabajando en innovaciones de concurrencia en Java y JVM: subprocesos virtuales, fibras y continuaciones. Lo más probable es que el lanzamiento de estas funciones sea gradual. Por el momento, solo hay versiones de acceso anticipado para compatibilidad con subprocesos virtuales. Hablando específicamente de subprocesos virtuales, su objetivo principal es simplificar el modelo de desarrollo de subprocesos múltiples en Java mediante el uso de millones de subprocesos livianos con la misma semántica que los subprocesos de plataforma normales. Debajo del capó, estos subprocesos se gestionarán dentro de ForkJoinPool y los subprocesos de la plataforma los reutilizarán.

¿Cuáles son las previsiones para el desarrollo de Java en el mundo de las tendencias globales: microservicios, arquitectura en la nube, blockchain, IA?

Andréi Rodionov:

Si hablamos de tendencias globales, no han cambiado mucho. Como antes, la tendencia principal sigue siendo Kubernetes y la infraestructura que lo rodea en forma de malla de servicios . La malla de datos también está ganando popularidad como una especie de abstracción para gestionar fuentes y almacenamientos de datos distribuidos.