Java con David Gómez

Pues buenas de nuevo en otro capítulo de Codeadores. Hoy tenemos un invitado especial que va a hablar de otro lenguaje diferente, pero que tiene ya muchos años. Es un lenguaje muy maduro que ha ido evolucionando con el tiempo, porque a diferencia de otros lenguajes como Fortran, COBOL y demás, que parece que se han quedado un poco estancados, Java, desde que salió en los años 90, no ha parado de crecer. Y aunque su ecosistema se ha visto nutrido de muchos lenguajes que ahora después hablaremos, siempre ha salido fortalecido y siempre ha sido un lenguaje que se ha hecho notar. Hay muchas empresas que apoyan Java y en este caso David Gómez, que es nuestro invitado, es también organizador del MadridJUG, del grupo de usuarios de Java. Y bueno, David, si quieres presentarte. Y yo siempre hago la pregunta de cómo te introdujiste en la informática. Así que si quieres contarnos primero acerca de la informática, aparte de presentarte.

Hola, pues buenos días, buenas tardes, buenos lo que sea cuando nos escuchen. Pues nada, primero muchas gracias por invitarme, por el contacto y dar la oportunidad de hablar, de pasar un rato hablando de Java. La verdad que es un lenguaje, dices tú, no sabía si decías Cuando has hecho la referencia, tiene muchos años, no sabía si te referías a mí o al lenguaje, podría casi aplicar a cualquiera de los dos, pero sí, la verdad es que yo empecé, llevo ya más de, oficialmente trabajando llevo ya, tengo una experiencia de más de 20 años desarrollando, pero mi experiencia con el mundo, cómo yo me introduje en el mundo de la programación, Fue, yo recuerdo que era sexto de EGB y estamos hablando de EGB. O sea que sexto de EGB yo venía, mis padres siempre habían intentado que yo hiciese algo, actividades extraescolares. Había pasado por natación, por judo, por, y de repente en sexto de EGB en una actividad extraescolar vino un señor a presentar unos cursos de programación en BASIC y a mí me flipó, que me dejó completamente alucinado que ese señor podía darle instrucciones al ordenador y el ordenador podía dividir la pantalla del ordenador en X partes iguales. Si él ponía 3, pues le dividía la pantalla en 3 partes iguales. Si le dividía 6, se la dividía en 6 partes iguales. Creo que también ahí ya empecé a desarrollar un poco de vamos a llevar las cosas al límite, porque me acuerdo que una de las primeras cosas que le pregunté, dice, ¿qué pasa si le pides a la pantalla que te la divida en 1000 partes iguales? Y al final ocupaba más las líneas de separación que la propia pantalla, porque la resolución de las pantallas no eran tan grandes, pero a mí me dejó alucinado pues esa capacidad de que le podías programar a la máquina. Y entonces yo llegué a mi casa y le dije, quiero que me apuntéis a este curso de programación. Entonces me apuntaron a BASIC, luego hice un segundo curso de BASIC, luego me apuntaron a una academia para hacer QuickBASIC, luego pasé a hacer un curso de programación en No sé si también algo de Turbo Basic. Luego me apunté a otra academia a hacer COBOL. Todo esto mientras yo iba pasando por el instituto. Lo de COBOL, bueno, me parecía como más aburrido, sobre todo porque yo era un adolescente y era como demasiado corporativo, ¿no? Me divirtió más hacer cosas con BASIC. Recuerdo que por aquel entonces mi madre se apuntó a hacer un curso de programación también, y entre los dos desarrollamos la aplicación de gestión de la empresa de mi padre. Entonces eso fue la primera vez que yo dije, jolín, esto es útil para algo. Y eso ya mientras estaba en el instituto orientó mi carrera a decir, bueno, pues yo quiero hacer, yo quiero seguir desarrollando software. En mi caso, yo siempre suelo decir que soy una rara avis porque todo el mundo que le preguntas dices, ¿cómo te iniciaste? Y todo el mundo quería programar juegos. Pero a mí lo que me pareció realmente útil es que entre mi madre y yo fuimos capaces de programar la aplicación de gestión de la empresa, de la empresa familiar. Y entonces esa utilidad, pues sí, lo de los juegos estaba bien, yo jugaba y hacía mis pókers como todo el mundo de tus revistas, pero a mí lo que realmente me pareció súper útil es poder crear una aplicación que a mis padres les redujo el trabajo de su empresa familiar. Y entonces, a partir de ahí, decidí que quería hacer ingeniería informática. Hice ingeniería informática. Luego empecé a programar. Inicialmente empecé a programar en Pascal, luego en las empresas en 4GL, y luego enseguida pasé ya a programar con Java. En algún momento programé también con Delphi, pero desde muy prontito empecé a programar con Java. Creo que empecé, mira, el otro día tengo por aquí un proyecto fin de carrera de un compañero que era el primer editor visual que yo conocí en español para Java. Y pone aquí arriba, el otro día lo publiqué en redes sociales, JDK 1.2.2. O sea que esta fue, y con esto conocí yo Java. Entonces es mi primera versión de Java y desde la versión 1.2.2 he estado haciendo cositas con Java. Así que bueno, pues con este lenguaje siempre ha sido mi lenguaje principal. He hecho cosas con otros lenguajes, pero mucho tiempo he estado con Java y he visto la evolución. He visto y he sufrido la evolución de Java durante todos estos ya casi 30 años, que celebramos el 30 aniversario. Pues el 20, a finales de mayo, 23 de mayo de 2025, hace ya 30 años de la liberación del lenguaje. Queda poco.

Sí, sí, quedaría poquito para que cumpla sus 30 años. La verdad es que hay pocos lenguajes que hayan estado tan activos y hayan visto su trigésimo cumpleaños estando, bueno, siendo uno de los lenguajes principales, incluso en los índices TIOBE. Sobre el lenguaje, porque empezaste ya a aprenderlo y a utilizarlo cuando, supongo que en tus primeros trabajos y en tu etapa laboral.

Sí, yo ya te digo, conocí el lenguaje pues cuando haciendo el proyecto fin de carrera, uno de mis compañeros más cercanos con quien había estado haciendo prácticas y demás, pues me dijo que él decidió, Javi Nieto, decidió que iba a hacer su proyecto fin de carrera en un lenguaje nuevo que estaba, parecía que era interesante, pero que no había editores visuales todavía. Y me dijo, dice, se llama Java. Y entonces bueno, con aquello de probar su editor y hacerle de beta tester del proyecto fin de carrera, pues me empecé a introducir en el lenguaje. Y viniendo de C, la promesa esta que ofrecía de olvídate de la memoria, la gestionamos nosotros por ti, a mí me resultó muy atractivo. Porque eso de dejarse recursos cogidos pues es uno de los problemas que tenemos todos los desarrolladores, bueno, que tienen todos los desarrolladores. Nosotros siempre somos buenos, pero siempre tenemos algún amigo que se dejó memoria sin liberar o una conexión a base de datos sin liberar. A nosotros no nos pasa, pero todos conocemos algún caso. Entonces esta gestión de los recursos, este nivel de abstracción de decir no tienes que trabajar directamente con los punteros de memoria, si nosotros te damos toda esa gestión de la memoria por ti fue la cosa que más me atrajo de primeras en comparación con C y la orientación a objetos que por aquel entonces pues yo los lenguajes que había utilizado con orientación a objetos era un poco de C++ o Smalltalk, pero aquí me pareció la sintaxis mucho más potente. Empecé con proyectos míos personales porque yo laboralmente al principio, como te digo, trabajé con 4GL, luego ya en entornos más visuales trabajé con Delphi, que era como la evolución de Pascal, pero enseguida que pude, en uno de mis primeros trabajos, ya sí empezamos a utilizar Java y para mí eso fue la gran oportunidad, empezar a montar un laboratorio de comercio electrónico en una consultora Yo me introduje allí y a partir de ahí, bueno, pues todo ha sido con Java. Y la verdad es que, bueno, la evolución, como te digo, si pienso cómo era el Java de entonces, donde utilizábamos JSPs, donde pues prácticamente todo lo tenías que dejar visto desde el servidor, donde incluso la Toda esa gestión de memoria era mucho más compleja, aunque tú no la utilizabas, pero siempre tenías que tener mucho cuidado con el garbage collector, cómo entraba, cuándo entraba, las pausas que te podía crear. Todo eso ha evolucionado muchísimo y la verdad que ahora ves el lenguaje y, bueno, pues si yo pienso, si en aquel momento me hubiese hecho un fast forward y me hubiesen dejado ver un trocito de código ahora, probablemente diría eso no es Java. Y bueno, yo creo que eso es fruto de, yo siempre digo que Java, una de las grandes cosas que ha tenido es que Java siempre llega, siempre evoluciona. Entonces se le critica mucho que es lento, se le critica mucho que es como un monstruo, se compara mucho con el COBOL. Es fácil esa tendencia de relacionarlo porque es un lenguaje que lleva muchos años, que es muy robusto, es un lenguaje muy empresarial, sobre todo inicialmente cuando teníamos las dos versiones, teníamos el SDK, el Java Standard Edition, y el Java Enterprise Edition, el J2EE o el JEE después. Luego ha evolucionado Jakarta, han salido otros frameworks, pero sí que es verdad que toda esta parte empresarial fue una cosa que Java permitió que se introdujese mucho en el mundo empresarial Y que de alguna forma se ha identificado, ha sido parte de su éxito porque ha permitido realmente poder utilizar Java en proyectos donde hoy por hoy nos parece muy natural tener la portabilidad, pero inicialmente los primeros proyectos, claro, tú tenías que pensar sobre qué plataformas se iban a ejecutar. Entonces tenías que hacer, cuando programabas en C o programabas en, tenías que saber que se iban a ejecutar en una determinada plataforma. El hecho de con Java poder estar programando en una plataforma y que luego se pudiese ejecutar en cualquier otra, pues también era otra cosa muy, muy potente. Entonces, Java se introdujo muy bien en todo ese ambiente empresarial y ha sido muy robusto y muy consistente durante muchos años. Y para mí, la mayor capacidad que ha tenido es que, aunque se le critica que ha sido lento en la evolución, Como yo digo, Java llega al final, evoluciona y evoluciona de forma inexorable. O sea, va adaptando, va evolucionando y va llegando. Cosas que la gente echa en falta o que se le atribuyen a Java como una carencia, al final Java las va solucionando, las va incorporando. Entonces lo que hace es que todo ese código empresarial o ese código legacy, entre comillas, acaba pudiendo ser mantenido dentro del mismo entorno y dentro del mismo ecosistema. Ha habido muchos retos, diría, en la historia de Java, retos de la informática, retos de pasar de un entorno donde la distribución era cliente-servidor y tenías que distribuir y luego pensar que tu aplicación de escritorio se podía ejecutar en varias plataformas distintas, o que los servidores podían ser distintos. Luego se pasó a sistemas más web donde el reto de Java era cómo se relacionaba con esa parte web. Se intentó con las JSPs o con otros frameworks que intentaban darte esa parte visual. Luego ahí vino otros lenguajes donde venían a cubrirte esa parte. Ahora también Java está llegando a esa parte visual también de otra forma, aunque quizá no es lo más conocido. Pero insisto, todos estos retos que a Java se le han ido poniendo, luego cuando vino los sistemas distribuidos, los sistemas en cloud, la ejecución nativa de aplicaciones, porque Java es un lenguaje interpretado, pero esa ejecución nativa que sea mucho más rápida, todo eso ha sido pasos, retos que Java ha ido asumiendo y ha ido acabando adaptando. Entonces lo que ha hecho es que desde el punto de vista empresarial, desde el punto de vista de utilidad del lenguaje, es una apuesta, yo diría que es una apuesta bastante segura en general. Entonces, porque lo que hoy no tiene Java lo puede tener dentro de 2 años. Es verdad que tarda en desarrollar, pero acaba llegando allí. Y no solo eso, no solo el lenguaje. Antes hablábamos un poquito que para mí es muy importante Java. Miren, antes mencionabas MadriJag. MadriJag o Madrid JUG. Las siglas de JUG inicialmente es de Java User Group. Sin embargo, nosotros en Madrid JAG hace mucho tiempo que decimos que la J no es de Java, sino de JVM. Y es ese ecosistema que tiene Java alrededor que ha ido fomentando otros lenguajes que han ido también permitiendo evolucionar y muchas veces han retroalimentado la propia evolución de Java. Cómo se ha ido adaptando. Muchas veces lenguajes como Scala, como Clojure, como Kotlin, como cualquiera de los que corren en la JVM, que son cientos. Creo recordar que, no sé si hay por ahí una charla en una conferencia, no sé si fue en un CodeMotion hace años, que había alguien que había hecho un listado de todos los lenguajes que había sobre la JVM. Te estoy hablando de hace años. Y le salían más de 100. Entonces todo ese ecosistema que ha proporcionado la JVM, que la JVM al final es la máquina virtual de Java, pero toda esa plataforma que ha proporcionado Java también ha permitido que surjan muchos otros lenguajes más específicos de los cuales Java luego se ha podido ir retroalimentando y ha podido ir evolucionando. Entonces es Ya te digo, a mí me parece una apuesta muy, muy segura. Y bueno, pues la prueba es que tiene 30 años, vamos a hacer 30 años, y hará muchos más seguramente.

Te iba a preguntar qué te gusta del lenguaje, pero creo que ya queda claro que estaba en la gestión de memoria, la orientación a objetos, la evolución propia del lenguaje. Y de último comentábamos de la retroalimentación que ha ido experimentando con la cantidad de lenguajes que han ido surgiendo sobre la Java Virtual Machine. Te iba a preguntar también que, claro, como hemos hablado que es un lenguaje que va evolucionando, quizás las fricciones que hayas podido experimentar a lo largo del uso de este lenguaje no son las mismas con el tiempo. Y porque yo recuerdo incluso que cuando salió Java 5 una de las cosas que más festejamos fue el printf, que éramos usuarios de C y lo echábamos de menos, y entonces nos vino genial. Pero eso venía incluso con otra adición, otra característica, que eran los variadic arguments que podías meter en las funciones. ¿Qué fricciones has ido tú experimentando, aunque se hayan ido resolviendo con cada versión?

Pues mira, yo creo que, como dices, Java 5 yo te diría que es uno de los puntos de los hitos, de las cosas, de las versiones que ha marcado más un cambio de tendencia en la evolución de Java. Ha habido otras, pero la primera que yo recuerdo así fue Java 5. De hecho, hasta tal punto que recuerdo ir hablando con un compañero en el autobús de vuelta al trabajo y decirle, José, tengo la sensación de que con Java 5 tenemos que aprender Java de nuevo. Porque efectivamente tenía los genéricos, tenía los varargs, tenía Tenía, hay cosas, fíjate, que yo luego me he tenido que enfrentar a ellas y no recordaba que no existían antes de Java 5, como los import static. Los import static no se podían hacer antes de Java 5, y es cosas que das ya por sentado. El printf que comentabas tú, hay mogollón de cosas que tendemos a dar por sentado. Yo te diría que los puntos un poco más de fricción, o los que yo recuerdo Algunos diría que están más o menos vigentes ahora mismo, pero los puntos de más fricción que yo recuerdo han sido el tema, por ejemplo, de la concurrencia. Java ha sido siempre un lenguaje que se orientó para tener soporte de concurrencia por estos entornos más empresariales y de alta escalabilidad y de rendimiento que tenía que tener. Pero es cierto que Java 5, por ejemplo, introdujo, lo solventó bastante bien. Fue una de las cosas que a partir de Java 5 mejoró mucho con nuevos constructores. Hay un libro por ahí que es el Java Concurrency in Practice, que describe mucho del ejercicio que hizo Brian Goetz en proponer los nuevos constructores de concurrencia, y que básicamente se han mantenido desde Java 5. Han evolucionado, se han ido complementando, han ido apareciendo nuevos constructores, pero diría que hemos pasado a tener muchos, Java 5 provocó el gran cambio, luego hemos tenido más recientemente pues el tema de los virtual threads o anteriormente nuevos controladores o nuevos componentes de control de concurrencia que se han ido introduciendo o cómo se han adaptado estructuras de datos internas para tener soporte de concurrencia. Entonces ese te diría que es el primero. Luego más recientemente creo que hubo otro momento bastante crítico con todo el tema del paso a sistemas distribuidos y altamente escalables. Con esto me refiero a todos estos sistemas que basados en la carga automáticamente te levantan, son capaces de levantar nuevas instancias para que no tengas que gestionarlo. Yo recuerdo que en este sentido Google App Engine era una de las primeras plataformas que plantearon que ellos te prometían que tú podías hacer tu aplicación, tú la desplegabas y ellos te prometían que siempre iba a responder, iba a responder en menos de no sé cuánto tiempo. Y de ello ellos se encargaban internamente de levantar cuantas instancias necesitasen para que tú no tuvieses que estar pendiente de levantar clústeres y levantar. Entonces, si tenías un pico, ellos te decían que te levantaban todas las instancias que tenían. Pero bueno, esto funcionaba muy bien porque el App Engine tenía un primer API en Python, y entonces con esto funcionaba muy bien. Si tú subías tu aplicación en Python, funcionaba muy bien, pero tenía una posibilidad de hacer subir aplicaciones en Java. Y el problema es que en Java, claro, esto es un reto porque levantar una aplicación, levantar una instancia para que te responda en el tiempo que tú lanzas una petición, pues es un reto. Entonces, ¿qué hacía App Engine? App Engine en las primeras versiones, recuerdo que había, ahora no recuerdo exactamente los detalles, pero había clases o había cosas que no se podían utilizar, no te permitía utilizar cosas del lenguaje, precisamente porque era lo que más podía ralentizar el arrancar una aplicación. Entonces el reto que había en este caso era pues el tiempo, y esto es una cosa que tradicionalmente la hemos tenido durante mucho tiempo, el tiempo de arranque de las aplicaciones. Porque claro, para arrancar Java tienes que arrancar la máquina virtual, tienes que hacer toda la parte de class loading, ya no digamos si encima tienes alguna aplicación que está basada en Spring o en algún framework de estos de inyección de dependencia que hace todo un proceso de montar tu aplicación y muchas veces de darle asteroides. Spring, por ejemplo, mucha de la funcionalidad que hace la hace a base de añadir proxies o de añadir recubrimientos en tiempo de inicialización, en tiempo de arranque. Entonces todo eso es tiempo que vas consumiendo. Claro, esto en un sistema distribuido de cloud o de cloud nativo que es muy difícil y es uno de los grandes retos que yo recuerdo recientemente en Java. Se ha ido solucionando primero saliendo otras máquinas virtuales o saliendo otros frameworks que van intentando hacer algo de compilación ahead of time para ir avanzando y todo ese proceso inicial adelantarlo lo máximo posible. Probablemente ha tardado y Java se ha ido alimentando de cómo lo estaban resolviendo otros lenguajes, pero al final ha llegado allí. Yo creo que todavía hay cosas, y de hecho hay un proyecto, el proyecto Leyden, que es un proyecto que lleva un año y medio, 2 años, pero no hay todavía nada real en la JVM. Y el proyecto Leyden, pues por ejemplo, está orientado a dar una vuelta de tuerca más, porque ahora mismo ya tenemos formas de arrancar una máquina virtual y sacar una especie de snapshot y ese snapshot poder recuperarlo. Ahí en la máquina virtual hace poco se introdujo una funcionalidad que es el CRAC, que es Coordinated Restore at Checkpoint, que básicamente eso lo que hace es permitirte sacar una snapshot de un momento determinado de cómo está la JVM y poder rearrancar a partir de ahí. Eso lanza muy bien el poder instanciar sistemas más rápido. Hay otros frameworks como Quarkus, por ejemplo, que te hacen una compilación nativa y te arrancan muy rápido. Hay máquinas virtuales como RealVM que también puedes utilizarlas con aplicaciones Java que te permiten arrancar muy rápido. Micronaut, por ejemplo, Micronaut tiene soporte para utilizar el CRAC y también te permite arrancar rápido. Entonces hay todo un ecosistema alrededor que ha ido haciendo que eso vaya más rápido. Pero por ejemplo ahora Project Leyden, que es un proyecto que está— la evolución de Java desde hace unos años se divide en distintos proyectos. Entonces Project Leyden son funcionalidades que están explorando, que están añadiendo a la JVM, que van orientadas precisamente no solo hacer que el arranque sea mucho más rápido, que cuando tú compilas no compiles solo a código bytecode de la máquina virtual, sino a código nativo de la plataforma sobre la que vas a correr, sino que además, por ejemplo, el Project Leyden, una de las cosas que están intentando es, o que están trabajando, es hacer que todas las optimizaciones que hace la máquina virtual también estén incluidas en ese paso nativo. Porque, por ejemplo, una de las ventajas, otra de las ventajas que tiene Java es que la plataforma, la máquina virtual, nos permite hacer muchas cosas. Ya no es la gestión de memoria por nuestra parte y los garbage collectors, que además cada vez evolucionan, toda la gestión de memoria y toda la gestión de garbage collectors cada vez van evolucionando a mejor. Sino que la máquina virtual también tiene una serie de componentes ahí que están haciendo cosas sobre nuestra aplicación. Por ejemplo, la máquina virtual una de las cosas que está haciendo está inspeccionando el bytecode, el código intermedio que está ejecutando, y es capaz de optimizarlo en función de los patrones de uso, de la carga que tenga el sistema, y la máquina virtual está viendo que hay determinado código que se está invocando muchas veces, es capaz de optimizarlo, es capaz de hacer inline de llamadas de métodos y traerse el código de un sitio a otro para que evitarme una llamada y así poder ser más rápido. Es capaz incluso de identificar código muerto, código que por lo que sea no se está ejecutando y lo puede eliminar. Entonces todos esos optimizadores son cosas que están ocurriendo mientras se está ejecutando la máquina virtual. Bueno, pues el Project Leyden va un poquito más allá y lo que intenta es que cuando yo levanto una máquina, una instancia, esté optimizada ya no solo con código nativo, sino con el código nativo equivalente a la optimización que habría hecho la máquina virtual en base a determinados patrones de uso. Esto es un poco tricky y por eso están probando cosas y están, pero esto es una de las cosas que está ahora mismo en el roadmap a futuro. De esto han hablado, hay vídeos por ahí de charlas de la JVM, de la JVM, de la JVM, del Language Summit, ahí hay una charla que es precisamente que habla del proyecto Leyden. Entonces, este es el segundo de los grandes retos que yo recuerdo recientemente, que es toda la adaptación al mundo de cloud, cloud nativo, sistemas elásticos, y que Java sea más rápido cada vez de evolucionar. Parte se ha solucionado y parte aún todavía está por mejorar.

Yo recuerdo también otro de los cambios que me llamó mucho la atención cuando salió Java 8, que incluía muchas de las mejoras, bueno, mejoras no, sugerencias que había hecho Scala para la Java Virtual Machine, e hizo que Java tomase un poco más de ese sabor funcional que llevaban otros lenguajes sobre la Java Virtual Machine como Scala, Clojure. ¿Tú crees que, o sea, porque después de Java 8 llegó Oracle y empezó a Es decir, bueno, cada 6 meses vamos a ir liberando una nueva versión de Java. ¿Crees que ese cambio de casi como tomar esas mejoras que venían de esos lenguajes funcionales y esas liberaciones más periódicas— comentábamos antes de que Scala fue considerado casi como el Better Java, ¿no? Pero llegó un momento en el que claro, si esas características las introduces de nuevo en Java ¿Realmente tiene sentido saltar a Scala? Porque también recuerdo de esa fecha muchas empresas que habían saltado a Scala y volvían de nuevo a Java. ¿Cómo viste tú esos cambios?

A ver, pues yo creo que esto fue una parte de Java 8. Antes decíamos que Java 5 fue probablemente el primer gran cambio, el primer hito que yo recuerdo así de decir esto ha cambiado brutal. Java 8 fue el segundo, y por varias razones. La que mencionas es una de ellas, que es precisamente toda esta incorporación de los streams y de todo ese feedback de las lambdas, todo eso que permitió una especie de un Java más funcional. Que eso luego habría que matizarlo, porque efectivamente mucho venía de Scala. Curiosamente, este, por ejemplo, es uno de los casos donde yo te digo que las evoluciones en la JVM han permitido que otros lenguajes como Scala se beneficiasen de ello. Yo recuerdo, por ejemplo, fíjate, nosotros vemos el cambio en Java 8 no solo por la parte funcional, sino por lo que vino después con Java 9 también, que es la introducción de la modularidad y el release cadence que has hablado tú. Pero todo esto viene precisamente del cambio entre Java 6 y Java 7. Y aquí hay una parte de la historia de Java. Yo siempre, recientemente en el MadridJAC dimos una charla un poco presentando las novedades de Java 21. Bueno, esto fue el año pasado ya, pero en la primera parte a mí me tocó, fue una charla que dimos entre varios organizadores y varios miembros del Java User Group de Madrid, y a mí me tocó un poco poner la introducción y poner en el contexto histórico. Y pensándolo, cuando empecé a hacer un poco la revisión del timeline de Java, me di cuenta que efectivamente hice esta pequeña analogía de que hasta Java 5 Java era como el bebé, como el niño. Entre Java 5 y Java 8, 9 es lo que yo llamo probablemente a nivel de evolución del lenguaje lo que yo llamo la adolescencia, porque es cuando realmente Java sufrió más en cómo tenía que evolucionar y hacerse mayor. Y por ejemplo, muchas de las cosas que no recuerdan, y lo aterrizo en relación a Scala, la programación funcional y el nuevo release cadence. En Java, entre Java 6 y Java 7, a partir de Java 6 dijeron que iban a meter el concepto de modularidad. Bueno, Java 7 tardó una barbaridad de tiempo en salir, nos y tardó 2 años y medio para que al final Java 7 fue una versión que desde el punto de vista del desarrollador Java se le criticaba mucho que era azúcar sintáctico lo que traía, porque todo lo que habían presentado era azúcar sintáctico. En realidad no había una funcionalidad nueva en el lenguaje que dijiste, guau, por esto me merece la pena cambiar. Lo que sí habían hecho era cambiar internamente bytecode que había disponible en la JVM. Y uno de ellos era el invoke dynamic. El invoke dynamic precisamente fue una de las cosas que Scala llevaba pidiendo o quiso o se benefició para poder hacer determinadas cosas que tenían las siguientes versiones de Scala. Esto lo que llevó es que Java luego pudo incorporar eso en Java 8. Java 7 que sacó la especificación de la máquina virtual y del bytecode permitió que otros lenguajes pudiesen empezar a hacer utilización de determinadas funcionalidades. ¿Qué ocurre? Que otros lenguajes como Scala, por ejemplo, una de las cosas que Scala surgió es decir, mira, nosotros no queremos mantener la promesa de la compatibilidad hacia atrás porque eso nos va a permitir evolucionar el lenguaje de una forma mucho más sencilla. Eso tiene una ventaja y es que efectivamente puedes evolucionar más rápido. Cuando ves que te faltan cosas las rehaces y en la siguiente versión puede ser mucho más óptimo. Tiene un inconveniente, que es que hay veces que entre versiones rompes cosas, y entonces tienes que efectivamente aprender lo que antes decíamos de con Java 5 tengo que aprender Java de nuevo, pero puedes seguir utilizando el Java que conocías. Lo que pasa es que te vas a perder muchas de las cosas. Insisto, con Scala puede romperse cosas entre versiones, entonces hay cosas que sí que efectivamente pueden cambiar, pero eso les permite evolucionar. Java 7, otra de las cosas que prometían y fue una de las razones por las que se retrasó mucho la evolución de Java 7 fue el hecho de que se iba a meter la modularidad. Y la modularidad no llegó con Java 7, pero es que no llegó con Java 8 tampoco. Y al final llegó con Java 9 y porque hubo una especie de— de hecho hubo también bastante ruido porque intentaron retrasarla pero luego al final dijeron mira tenemos que sacar la modularidad ya sea como sea. En aquel momento la modularidad de Java se quería comparar con OSGi, que era un framework de modularidad mucho más completo. Entonces digamos que todo esto fue una fase como muy, ¿cuál es la palabra?, como muy convulsa en cómo evolucionaba Java, cómo estos problemas, pero también permitió que otros lenguajes fuesen avanzando camino y retroalimentar es toda la funcionalidad. Y con esto llegamos a Java 9 y el cambio, a partir del cambio de release cadence. Entonces, el cambio de release cadence, también en aquella época se reorganizaron la forma de evolucionar los lenguajes, se sacaron los distintos proyectos, el Valhalla, Panamá, que eran subproyectos que se iban a orientar en funcionalidades específicas. Y entonces todo esto que eran JSRs o JEPs, ahora son las propuestas de mejora de Java, Java Enhancement Proposals. Entonces todo esto se van agrupando en torno a proyectos y entonces lo que se hace es, ahora voy a, cuando una funcionalidad está en un estado más o menos estable, la voy a incorporar a la siguiente release, pero ya no voy a tener como nos pasó con Java 7 o con Java 9 o con Java 8, ya no voy a tener que retrasar la release simplemente porque esta funcionalidad no está lo suficientemente estable. Entonces a partir de este nuevo cambio de release cadence lo que se estructuró se organizó mucho mejor todas estas funcionalidades de tal forma que ahora se van incorporando, bueno pues ya sabemos que tenemos 2 releases al año, Y que estos momentos, estas releases dan una oportunidad para ir introduciendo, para decir bueno pues cuando tengo esta funcionalidad, si no es en marzo será en septiembre, pero la voy a incorporar. Y además establecieron mucho mejor la forma en la que se va a introducir esa funcionalidad porque se define una funcionalidad en 3 modos: puede estar en modo incubator, Puede estar en modo preview o puede estar en modo final. Y además todo eso está regulado. Y todo eso se reguló precisamente con esa, durante esta fase de adolescencia que llamo yo, ¿no? Desde Java 5, o desde Java 6 más bien, desde Java 6, Java 7 hasta Java 9, todo esto fue, se fue regularizando, se fue normalizando. Entonces ahora tenemos una forma de evolución del lenguaje mucho más madura, te diría. Entonces yo digo que desde Java 11, que fue la primera release que ya tuvimos bajo esta release cadence, es cuando yo digo que Java ha alcanzado su juventud, su nivel un poco, ya ha dejado atrás la adolescencia y ya tenemos una forma de ir progresando mucho más estable. Porque ahora lo que decía, estas funcionalidades, pues cuando una funcionalidad está Bueno, yo la puedo liberar primero en modo incubator, que quiere decir, oye, yo la pongo pero no está activa en la JVM, la tienes que activar de una forma específica. Y además el consejo es no deberías utilizarla porque lo que queremos es que esté ahí para que la puedas probar, pero aquí sí vamos a poder romper el API, ya que una funcionalidad está en modo incubator en una release quiere decir que en la siguiente release puede ser que esa funcionalidad no esté o no esté igual o que hayan cambiado el API. Entonces es como coger lo mejor de los dos mundos, aquello que tenían otros lenguajes como Scala, que dicen bueno pues aquí puedo romper cosas. Normalmente cuando te ponen algo en modo incubator ya está, no te lo lanzan así de primeras, ya hay un cierto trabajo detrás y lo que te lo ponen en modo incubator es pues para evaluar qué uso potencial podría tener eso y que la gente lo pueda utilizar. Cuando ya el API está definido y está cerrado, pues tú lo puedes mantener en una release en modo preview. En modo preview quiere decir ya hemos decidido, desde los ingenieros del lenguaje han decidido que esta funcionalidad sí es útil, sí aporta cosas y que la vamos a mantener. El API es definitivo salvo algún bug o salvo alguna cosa, pero aún podemos cambiar detalles internos o podemos cambiar, optimizar o añadir cosas. Entonces los preview tienen esta labor. En principio el preview te prometen que solo va a haber 3 previews: first, second and third preview, y después de eso ya pasa a final. Igual las funcionalidades en modo preview ya puedes empezar a utilizarlas con una cierta confianza de que van a estar ahí, que nadie te las va a quitar, y que además están más o menos estables. Y demás. Y luego ya cuando llegan a final es la funcionalidad que ya tienes activa por defecto en la máquina virtual. Y en esto me hace gracia porque a mí me resultó muy curioso en una conferencia, en un JCrete, un open space que organiza Henk Cabot todos los veranos en Creta. Allí hay mucha gente normalmente, es un grupo bastante reducido de gente, pero tienes gente, pues eso, gente que ingenieros de la JVM o tienes a los champions allí, charlando y además, y recuerdo en una de ellas, no recuerdo quién fue, pero era uno de los ingenieros del lenguaje que contaba que la forma en la que Java deciden si van a introducir una funcionalidad en el lenguaje o no, en uno de los pasos que tienen, tienen varios pasos por supuesto, pero uno de los pasos que tienen es, hay un momento en el que hacen una lista de todas las formas potenciales en la que la gente podría utilizar esa funcionalidad de una forma no adecuada, que podría ser un riesgo. Lo cual me parece un ejercicio muy interesante porque al final lo que dicen es que si los riesgos superan a los beneficios deciden que no van a introducir esa funcionalidad en el lenguaje, o al menos tienen que rediseñarla o repensarla. Y esto viene, sospecho, de parte de esa evolución convulsa que tuvo Java en esa fase de adolescencia que llamo yo. Entonces al final toda esa época ha marcado que hoy por hoy tenemos un lenguaje pues con el cual yo me siento muy cómodo a la hora de evolucionar y a la hora de, es como sé que va a ser el lenguaje que yo siempre conozco y solo tengo que ir estando pendiente de cuáles son las novedades o me puedo incorporar a conocer las novedades en el punto en el que yo quiera, si están en incubator, si están en modo preview o directamente cuando ya sean final. Entonces para mí bueno pues Digamos que esa época fue bastante complicada, convulsa, pero creo que fue muy bueno el hecho de que estableció por fin entre Java 6, pero sobre todo entre la parte más visible fue entre Java 8 y Java 9 al 11, fue la fase donde más claro quedó que cambiaba la forma de evolucionar de Java. Probablemente se tomó con mucho miedo. También hubo mucho ruido, también porque Oracle en determinado momento introdujo que como iban a tener cadencia de 3 meses, o de 6 meses, perdón, el soporte que iba a dar iba a estar limitado. Se empezaron a introducir el concepto de las LTS. Entonces hubo mucho miedo porque también, no sé si interesado o desinteresadamente, o por error, pero bueno, yo tengo mi opinión personal, pero es personal. Entonces, pero sí que empezó a haber bastante miedo con que Java dejaba de ser gratis porque Oracle empezaba a cobrar licencia comercial y más allá de los 6 meses iba a pedir soporte. Entonces claro, nadie se planteaba cambiar la versión de Java cada 6 meses, cuando a la hora de la verdad casi es más fácil ahora hacerlo que antes. Pero yo entiendo que en entornos corporativos pues aún hay esa tendencia a mantener una versión que que sea más antigua. Pero con todo este miedo también influyó el tema de, bueno, si Java ahora lo van a hacer comercial, si Oracle va a cobrar por todo esto. Yo sé que hubo mucha gente que estaba pensando en dejar Java, dejar el ecosistema Java, pero afortunadamente también hoy otra de las ventajas que tiene Java y que a mí me encanta es toda la comunidad que hay detrás, no solo de desarrolladores sino de empresas que lo están soportando. Entonces A partir de ahí salió una iniciativa también JDK, OpenJDK. Hay mogollón de iniciativas que siguen empujando Java un poco al margen de la línea oficial, no al margen sino de forma complementaria de la línea oficial de Oracle. Oracle sigue siendo el responsable de evolucionar el lenguaje y la plataforma, pero luego digamos que la evolución de los binarios y la adaptación a distintas plataformas hay un montón de compañías y hay un montón de comunidad detrás que está dando ese soporte y dando esa seguridad y esa garantía. Entonces, insisto, al final es todo un compendio y más allá del lenguaje, todo lo que hay alrededor de la plataforma pues es que da mucha confianza para seguirlo utilizando.

Estábamos hablando de que ahora ya se estructuran los cambios con los JEP, son los documentos estos que proponen nuevas mejoras, cambios Creo que serán mejoras más que cambios. Tú has dicho que vas siguiendo las novedades de cada cosa que va saliendo, pero tienes, o sea, mantienes el seguimiento de algún JEP que digas mira, este lleva aquí tiempo, me gustaría que saliese. O sea, ¿hay algunos de estos documentos que sigas y que incluso presiones a ver si sale o no sale?

Bueno, ahora mismo estoy ahí Hay uno que sé, ahí hay más que un JEP en concreto. Sí que había una cosa que a mí me gustaba mucho ver, y es por curiosidad, y esto me encanta porque me parece también muy identificativo de lo que hay en cada cambio. Ahí en concreto siempre me ha interesado bastante ver cómo van evolucionando los distintos garbage collectors, porque es una de las cosas que afecta más al rendimiento. De las aplicaciones Java. Entonces, qué nuevos garbage collectors van saliendo, cómo se van aplicando, en qué momento van cambiando. Entonces no es un JEP en concreto porque cada garbage collector tiene su propio ciclo de vida y su propio equipo de trabajo. Hay otro que a mí me gusta mucho ver y es, insisto, y esto me parece un detalle de cuántas cosas cambian que no sabemos o que no experimentamos los desarrolladores Java. El cómo ha ido evolucionando la clase String en Java, porque la clase String es una clase que tenemos ahí desde siempre y la utilizamos. Lo que pasa es que, por ejemplo, la clase String es una de las clases más utilizadas en cualquier aplicación Java. De hecho, si tú haces un volcado de memoria de de cualquier aplicación Java, verás que si lo agrupas por tipos, verás que el array de caracteres, el array de char, en las versiones antiguas de Java es la estructura que más veces aparece en memoria. Y eso es porque viene del string. Entonces el string, una de las cosas que hacen es, siempre están mirando cómo se puede mejorar. Hace unas versiones, no sé si fue, aquí ya no recuerdo la versión, no sé si fue Java 11 o Java 8 o alguna un poco posterior, pero una de las cosas que hicieron es decidieron que cambiaban el array de chars al array de bytes e iban a gestionar todos los encodings de una forma distinta, de tal forma que si el encoding te permitía codificar cada carácter con un solo byte, se ahorraban esa memoria. Y solo con ese gesto, lo que implica que la implementación de la clase String es mucho más compleja, pero a la hora de la verdad, la memoria directamente en esta versión de Java, solo por cambiar la versión de Java y por el hecho de que la clase String estaba implementada de forma distinta, ya obtenías una mejora en el este de memoria. Y ahora últimamente, como digo, pues los JEPs que estoy más, o la funcionalidad que estoy más pendiente de ella por curiosidad, es la del proyecto Leyden. Todo lo que viene del proyecto Leyden, estoy suscrito a la, lo que pasa es que de momento estoy más curioseando, más intentando ver y entender qué es lo que están pensando. Hacer para mejorar todavía más los tiempos de arranque de Java, incluso y sin perder las optimizaciones que es capaz de hacer la máquina virtual por el hecho de que tienes el bytecode y no una compilación nativa. Entonces ahora mismo esas son, ahora mismo lo que tengo más interés es en, ya te digo, en cómo evoluciona toda la parte del proyecto Leyden, y históricamente lo que me ha gustado también mucho es toda la parte de de garbage collection y cómo esto evoluciona. Porque ahí también tengo que decir que Java ha hecho históricamente, ha hecho un trabajo, ha puesto muchísimo esfuerzo y hemos tenido muchísimos garbage collectors. La evolución de las políticas de garbage collection ha sido, bueno, pues la verdad es que hay mucha historia ahí detrás y ha mejorado mucho. Es algo muy estable y aún así sigue mejorando.

También me da la sensación que va a decir que no, pero ¿habría algo del lenguaje de Java que dijese no me gusta o no termina de gustarme y lo cambiaría de esta forma?

Hay una cosa que me tiene, me tiene el corazón dividido porque muchas veces no sé si entiendo, y es la crítica esta de que el lenguaje es muy verboso, que es verdad. Pero te voy a confesar que es la típica cosa que a mí me tiene dividido, porque no sé si es bueno o es malo. Yo soy de los que piensa que en el fondo el código lo escribes solo una vez, que si es más verboso por el hecho que tengo que escribir más, bueno, pero es verdad que si tengo que escribir más tengo que leer más, y también eso hace que a veces no sea todo lo conciso que podría ser. Creo que hay otros lenguajes dentro de la JVM que consiguen esta versión más concisa del código mucho mejor. Entonces aquí tengo que reconocer que es verdad que es una cosa que me tiene dividido porque muchas veces la parafernalia que tienes que escribir de código, las plantillas de código que tienes que escribir es demasiado comparado con la funcionalidad real. Pero tengo que decir que incluso ahí yo creo que Java está haciendo muy buen trabajo en evolucionar. Por ejemplo, tenemos cuando vas a utilizar beans y ya no quieres tener todos los getters y los setters, pues ya tenemos los records desde hace unas cuantas versiones, que es una forma mucho más concisa de tener objetos de datos inmutables que no te hace falta escribir el getter y el setter de forma específica, y solo tienes que escribir el getter y el setter si realmente quieres hacer algo distinto que devolver el valor directamente. Por ejemplo, de cara a toda la parafernalia para tener una simple clase, tener que escribir una clase y sobre esa clase tener un método estático main y meterlo en un paquete, eso ya se ha simplificado también con Java 21. Ya puedes directamente tener una función que la llamas. Entonces hay cositas, pasitos que se van dando para reducir toda esa verbosidad que tiene Java. Entonces yo te reconozco, esta es la parte que yo tengo un poco ahí del corazón dividido porque creo que necesariamente escribir más código no es malo per se, pero hay veces que escribimos demasiado, demasiado código. Y eso sí que es cierto que es una de las cosas que a veces Lo ves en otros lenguajes y ves que efectivamente otros lenguajes son mucho más concisos. Y aquí, por ejemplo, tengo que confesar que Kotlin en general hace un muy buen trabajo con tener una sintaxis mucho más concisa en determinadas cosas.

Recuerdo una frase que decían muchos programadores experimentados, la recuerdo de Eric S. Raymond y de Richard Stallman, los dos la pronunciaron en algún momento, de que para ser un buen programador hay que leer mucho código. Es decir, para poder escribir hay que leer antes bastante código. A mí me viene a la mente ejemplos de proyectos de Java que siempre he idealizado e idolatrado, como Cassandra y Kafka. Pero si tuvieses que recomendar a alguien que tomase un proyecto como ejemplo para aprender a escribir buen código en Java, ¿cuál sería?

Es una buena pregunta. Yo siempre, por ejemplo, no sé si es un proyecto, bueno, sí es un proyecto, pero no es un producto final. Pero a mí me ha gustado mucho históricamente cómo está escrito el framework de Spring. No sé si ahora mismo sería el mejor proyecto para eso porque Spring es tan sumamente grande que probablemente no sabrías ni por dónde empezar. Pero tradicionalmente yo siempre decía que Spring Source, Spring Framework, está muy bien escrito en el sentido de, por ejemplo, cosas que a mí me gustan mucho cómo gestiona es el propio framework cuando tiene una excepción, cómo es capaz de darte la información correcta y adecuada para que tú sepas dónde está el problema de la excepción. Cuando tú arrancas, no con tus proyectos, porque al final cuando tú lanzas una excepción en un proyecto que tú has hecho sobre Spring, pues al final es como tú lo tengas gestionado. Pero si tú estás construyendo una aplicación y hay un bean que te has dejado o algo que no has activado, en general Spring, el framework, cuando intenta arrancar el contenedor de inversión de control y algo no está como la información que tienes ahí es la correcta. O sea, te apunta, por ejemplo, es un ejemplo, cómo tiene hecha toda la parte de recubrimiento, de la parte de Spring AOP, la parte de recubrimiento cuando te mete el gestor transaccional. Esto es un poquito más complejo de leer, pero quiero decir, la forma en la que está escrito tradicionalmente A mí siempre me ha parecido un buen compendio de buenas prácticas. Es cierto que hace mucho que no me meto en las tripas de Spring porque esto me metía más cuando estaba dando los cursos de certificación de Spring en español. Entonces no sé cómo habrá evolucionado, pero no creo que se haya evolucionado a mal. Porque las buenas prácticas del código, ya te digo, cómo estaba escrito a mí me parecía que tenía bastante sentido. El problema que tiene hoy es que es un proyecto, Spring Framework, que ha crecido muchísimo. Y ya no solo Spring Framework, sino Spring Boot y toda la miríada de subproyectos que tiene alrededor para hacer un montón de cosas. Probablemente aquí lo complicado sea es por dónde empiezo, por dónde no perderme en el bosque, fijarme en algo concreto.

Y aunque Java se suele enseñar en las universidades, por lo menos en mi caso, y supongo que el tuyo, como habías comentado por lo del proyecto este de fin de carrera, si alguien quisiera aprender Java y no viene de la universidad o en su universidad por cualquier motivo no se ha dado este lenguaje y quiere introducirse, ¿cuáles crees tú que son los recursos o las prácticas más recomendadas para introducirse en el lenguaje?

Pues yo diría que hay que empezar por no agobiarse, porque Java es un ecosistema muy, muy, muy amplio. Puedes hacer muchísimas cosas. Ahí, si haces una sencilla búsqueda como de Java for Beginners, salen algunos recursos en Coursera, bastante adecuados. Hay una iniciativa en concreto que está auspiciada dentro de, por el propio lenguaje, por el propio Oracle, que es Java in Education. Y entonces aquí de vez en cuando Java in Education, no sé la URL, pero la podemos, la podemos, la puedo publicar en redes sociales. Es un proyecto básicamente que está coordinando a gente lo lleva Heather Bancura, que es la chairman del JCP, del Java Community Program. Y esta iniciativa en concreto, Java in Education, una de las cosas que está tratando es de compilar una serie de recursos y además no solo ponerlos a disposición de la gente, sino también recuperar feedback de gente que está en el ecosistema Java para ver cómo implementamos, cómo se mejora o se reduce la curva de aprendizaje de Java. De hecho, es curioso porque yo creo que de aquí salen algunas de las sugerencias de mejora del lenguaje para poder simplificar sintaxis y reducir algo de la verbosidad que tiene a veces, ¿no? Pero ya te digo, más allá de algunos cursos que yo he visto por ahí de Java for Beginners, que te van introduciendo un poco en los conceptos del lenguaje, y bueno, pues hacer pequeñas cosas. Yo buscaría que esos cursos estén, a ser posible, actualizados a las últimas versiones o al menos a una versión posterior a Java 21 porque con Java 21 es con la primera en la que se redujo ya la idea de tener que tener una clase y dentro de la clase un método estático y toda esta clase que esté en un paquete determinado para poder ejecutarlo. Ya se hace mucho más sencillo tener simplemente un script y un fichero, y con ese fichero lanzar tu aplicación Java. Entonces puedes empezar a aprender Java un poco quitándote toda la complejidad del sistema de paquetes, clases y demás. Entonces tú puedes empezar, si quieres solo el lenguaje, lo que es la sintaxis del lenguaje, puedes empezar escribiendo tus scripts, puedes empezar utilizando Java como un lenguaje de scripting. Y una vez que te vas familiarizando, pues ya te vas metiendo un poco en todo lo que son los conceptos de programación orientada a objetos, de las clases, las clases estáticas, interfaces, o en la parte de soporte a funcional que tiene. Pero yo empezaría por eso. Si veis un curso Java for Beginners, comprobad que está actualizado a Java 21, porque es donde te va a reducir más la curva de aprendizaje. Y si no, buscad la iniciativa Java in Education, que está auspiciada por el JCP, por el Java Community Program, que bueno, por los recursos que van liberando siempre están buenos. Hay también un, creo que este recurso está enlazado dentro del Java in Education, que es una consola online Java donde tú puedes tener, en Java tenemos también a partir de, ya no recuerdo qué versión, tenemos el JShell, que es un REPL, una consola donde tú puedes escribir directamente comandos Java, similar a como podrías hacer, como lo que tiene Python con los notebooks, donde tú puedes ir escribiendo tus comandos Java y puedes ir familiarizando con la sintaxis.

Y hay una consola online, hay un REPL online en Java, no recuerdo la URL, pero vamos, si lo buscáis está Y por último, ¿cómo ves el mercado laboral tanto para gente experimentada como tú como para gente que inicia en la carrera de Java como junior o que acaba de, que busca su primer trabajo después de aprender Java?

Pues como te decía, yo creo que el uso del lenguaje es muy, muy estable. Probablemente ahora pueda dar la sensación de que hay menos mercado simplemente porque hay otros lenguajes en los que hay muchas más, muchas más ofertas. Si tú ahora ves, hay muchas, muchas ofertas que te piden Python, que te piden— de hecho Python creo que el otro día salía un GitHub, decía que era el lenguaje más utilizado en los repositorios de GitHub, pero tienes ahora mismo muchas ofertas que te están pidiendo Node o JavaScript o algún framework JavaScript, y eso probablemente oculta un poco todo lo que hay con Java, pero yo sigo pensando que Java, o mi experiencia es que Java sigue teniendo mucha demanda y mucho soporte. Porque hay muchas aplicaciones que están utilizando y se van a seguir utilizando Java. Entonces también creo que ya hace muchos años que probablemente gente con más experiencia como yo estamos un poco encasillados. Entonces la gente te ve como, no, tú sabes Java y no eres capaz de hacer cosas con otros lenguajes, o sobre todo no vas a hacer nada nunca con JavaScript y tal. Bueno, Cuando a alguno le cuento que hace años monté una web con Node.js, la gente— el otro día lo hablaba con uno de los que lleva Madrid.js y decía, pero, ¿qué me dices? ¿Esto lo puedo grabar? Pues mira, Javi, hoy lo estoy diciendo aquí en público. Sí, yo he utilizado, he hecho webs con Node.js simplemente pues porque era la herramienta más adecuada para una web sencilla como era la que queríamos hacer en aquel momento, pero Aparte de ese encasillamiento, creo que lo positivo es tener la capacidad. Yo soy un defensor de la idea del programador políglota, aunque en casos como en mi caso yo esté un poco encasillado y la gente me considera que solo sé programar en Java, principalmente porque programo principalmente en Java. Pero bueno, pues yo estaba en proyectos también Hace años, pues cuando me tocó arrancar en un proyecto que estaba hecho parte en Java, parte en Scala, que utilizaba Akka Streams, y bueno, pues no lo había hecho nunca antes, y me metí, y en 6 meses pues habíamos desarrollado un conector para Kafka, que tampoco lo había utilizado antes, desarrollado con, bueno, con Java, Scala, AKKA, y estaba funcionando, estaba funcionando bastante bien según me cuentan. Pero volviendo a la pregunta inicial, yo creo que Java, y volviendo a lo que he contado de la evolución y cómo inexorablemente Java progresa y llega donde tiene que llegar, creo que Java es un seguro. O sea, tener Java en tu en tu cajón de herramientas y ser capaz de hacer cosas en Java te va a llevar, te va a permitir moverte. Porque luego no es solo Java, es muy fácil de Java pasar a Kotlin, de Java a todos estos better Java que van saliendo. Como decías antes tú, Scala antes era el better Java, ahora Kotlin parece que es el better Java. Y es verdad que Kotlin tiene cosas que a mí me gustan mucho, pero al final Java va llegando allí. Entonces, tener el recurso de saber programar en Java te permite moverte más fácilmente a otros lenguajes también que corren sobre la JVM, porque al final hay muchos conceptos o parte de lo que está pasando por debajo en la JVM, pues al final ya estás más o menos familiarizado con ello, aunque a veces el lenguaje luego cambie.

Pues bueno, ya llevamos una hora. Ha sido, la verdad es que ha sido muy emocionante y ha sido muy refrescante poder hablar contigo sobre todos estos temas, porque la verdad es que hacía tiempo que no me actualizaba con el mundo Java y me ha encantado todas las cosas que nos has comentado sobre la evolución que ha tenido el lenguaje y cómo sigue progresando. Me a punto de revisar Java 21 porque me has dejado ahí entre la JShell y la modularización, que me llama mucho la atención.

Y si quieres decir algo para cerrar, pues básicamente, bueno, sí, ya el último consejo es si vas a Java 21, échale un vistazo. Ahora hemos liberado Java 23, pero en marzo de 2025 se liberará Java 24 y en septiembre Java 25, y lo que viene va a ser otro, de hecho ya hay gente que está diciendo que puede ser otro de los grandes cambios junto con Java 5 y Java 8 que viene por el camino por la cantidad de novedades que tiene. Yo como reflexión de cierre pues diría que al final Java es un ecosistema, no es solo el lenguaje, es todo el ecosistema que es muy potente, es muy rico y creo que Pues todos esos que año tras año van diciendo Java está muerto van descubriendo que Java tiene todavía mucha vida por delante y además es muy estable y como digo yo es inoxorable, evoluciona y llega hasta allí. O sea que yo os animo a que sigáis y por ejemplo si queréis un poco compartir, aquí meto un poco el product placement, en el Java User Group de Madrid. Podéis acercaros, podéis acercaros porque allí nos encanta ver gente nueva, conocer gente nueva y seguir charlando y mantenernos al día de este lenguaje y plataforma que es robusto y es un seguro. Muchas gracias por invitarme, muchas gracias por tenerme. Encantado.

Muchas gracias, David, por haberte pasado. Y bueno, cerramos este capítulo de Codeadores y nos vemos la siguiente semana con otro capítulo. Muchas gracias por escucharnos y hasta otra.