Lanzamiento oficial de Java 25 / JDK 25

• Java 25 y su implementación de referencia JDK 25 fueron lanzados oficialmente
• Esta versión incluye 18 nuevas funciones JEP (Java Enhancement Proposal)
• Se aplicaron cambios importantes como la eliminación del port de x86 de 32 bits, Scoped Values, Structured Concurrency y mejoras en Primitive Types

---

Java 25 / JDK 25: lanzamiento oficial

• JDK 25, es decir, la implementación de referencia de Java 25, fue lanzado oficialmente como versión de distribución para producción
• El 15 de agosto de 2025 se publicó build 36, el segundo release candidate, y desde entonces no se han reportado bugs críticos (P1).
• build 36 es la versión final GA (General Availability), por lo que también puede usarse en entornos operativos

• Oracle distribuye oficialmente el build de OpenJDK basado en licencia GPL, y también se espera pronto la publicación de versiones compiladas por varios otros proveedores

Enlace oficial de descarga de OpenJDK

Funciones y mejoras principales

Esta release incluye 18 JEP (Java Enhancement Proposal)

• 470: Codificación de objetos criptográficos basada en PEM (preview)
• 502: Stable Values (preview)
• 503: Eliminación del port de x86 de 32 bits
• 505: Structured Concurrency (quinta preview)
• 506: Scoped Values
• 507: Soporte para Primitive Types en pattern, instanceof y switch (tercera preview)
• 508: Vector API (décima versión incubadora)
• 509: Perfilado de tiempo de CPU con JFR (función experimental)
• 510: Key Derivation Function API
• 511: Declaraciones Module Import
• 512: Compact Source Files y métodos main de instancia
• 513: Flexible Constructor Bodies
• 514: Optimización de línea de comandos Ahead-of-Time
• 515: Perfilado de métodos Ahead-of-Time
• 518: Muestreo cooperativo de JFR
• 519: Compact Object Headers
• 520: Temporización y trazado de métodos con JFR
• 521: Generational Shenandoah

Además de los JEP anteriores, esta release también incorpora cientos de pequeñas mejoras funcionales y miles de correcciones de bugs

Para más información sobre esta release y los detalles de cada JEP, consulta la
página del proyecto OpenJDK JDK 25

[ahwjdekf]

El mismo de siempre que vino el año pasado ni muerto deja de volver, ea, que siga el ritmo... ¿por qué sigues apareciendo una y otra vez?

[click]

Es una función que llegó en JDK 24, pero como en Java hay una fuerte tendencia a usar solo las versiones LTS, también vale la pena prestar atención a que con JEP 491: Synchronize Virtual Threads without Pinning ya no se produce el fenómeno de pinning de los hilos virtuales al usar la palabra clave synchronized.
A veces los benchmarks de hilos virtuales en entornos reales daban resultados más lentos, y en la mayoría de los casos la causa era el pinning.

[GN⁺]

Opiniones de Hacker News

• Creo que más programas nuevos deberían escribirse en Java o sobre la JVM; casi ya no existen las razones por las que Java perdió popularidad en el pasado, y ahora es un ecosistema muy estable y maduro. Un programa en Clojure que escribí hace 10 años sigue funcionando sin problemas, mientras que un programa escrito en TypeScript necesita mantenimiento y actualizaciones a los 6 meses.
  • Oracle es una gran preocupación. Es incómodo tener que cuidar no violar el EULA de Oracle al usar Java. Supongo que con OpenJDK estaría bien, pero preferiría usar otro lenguaje y no preocuparme por eso. C# también ofrece un entorno parecido a Java y se puede usar sin preocuparse por Oracle. En vez de estudiar cómo usar Java de forma segura, me parece mejor simplemente elegir otro lenguaje. Además, Java no es indispensable, así que hay muchas alternativas.
  • Java sigue siendo enormemente popular y muy usado en sistemas backend a gran escala. Me sorprende que aquí parezca haber tan poca gente que trabaje con ese tipo de sistemas; en mi experiencia, es casi imposible no encontrarse con Java.
  • Tengo la esperanza, aunque sea en secreto, de que Kotlin y Compose revivan las apps de escritorio sobre la JVM.
  • Creo que el área donde Java sigue en riesgo en términos de adopción es su cultura asociada. Muchos desarrolladores veteranos de Java y programas Java existentes están escritos de forma innecesariamente verbosa, aunque el lenguaje ya tiene funciones para escribirse de manera concisa como otros lenguajes modernos. Aun así, Java es tan grande que creo que todavía puede cambiar.
  • Me pregunto si que un programa en Clojure que escribiste hace 10 años siga funcionando bien se debe a la JVM o a la forma particular de Clojure. Yo tuve una experiencia parecida con proyectos en ClojureScript. Viejos scripts de nbb también siguen funcionando bien de inmediato, aunque a veces hay que retocar un poco alguna dependencia de npm. En cambio, con Python me ha tocado perder medio día por problemas de dependencias y manejo de venv.
• Java ha sido durante mucho tiempo una base tecnológica sorprendentemente sólida. No es el lenguaje más atractivo, pero siempre demuestra estabilidad. Una app hecha en Java 1.4 sigue funcionando bien en Java 21 LTS, y planeo actualizarla pronto a Java 25. Java es lo máximo.
  • Me pregunto dónde estaría hoy Java si no hubiera tenido las excelentes herramientas de JetBrains y su inteligente programa para estudiantes.
  • Aunque lo mantengo a cierta distancia, todavía recuerdo una app de Gmail hecha en Java que corría en mi teléfono Symbian táctil en 2009. Era realmente adorable y la usé bastante bien.
  • No puedo estar totalmente de acuerdo según mi experiencia. En varias empresas, cada vez que subían la versión de la JVM siempre había problemas grandes y hacía falta mucho retrabajo y muchas pruebas de nuevo. Yo me detuve por Java 17~18, pero la gente con la que trabajo casi nunca usaba versiones nuevas. En 2022, en un proyecto tuvimos que actualizar JVM 1.5, pero fue muy difícil porque librerías críticas de terceros solo soportaban versiones anteriores a Java 1.7. Intentamos conseguir el código fuente y compilarlo nosotros mismos, pero el alcance fue creciendo cada vez más. Fue duro por los desacuerdos con los gerentes, y al final decidí dejar a un cliente de primer nivel del Fortune 10. Según escuché, ese sistema todavía no ha podido actualizarse.
  • Quería volver a usar una app en Swing que escribí hace tiempo, y como parece que podría revivirla sin grandes cambios, estoy pensando en intentarlo.
  • La JVM y su ecosistema también pueden usarse junto con otros lenguajes como Scala y Clojure, lo que permite usos variados y atractivos.
• Me sorprende que haya tardado tanto en permitirse la validación y transformación de parámetros antes de llamar a super en el constructor. Siempre me pareció algo contrario a la intuición.
  • Llevo usando Java desde antes de JDK 1.0, y aunque esto siempre me molestó, con el tiempo me adapté y me acostumbré a las soluciones alternativas.
  • Si usabas una función static para el proceso de validación dentro de los parámetros de super, en la práctica igual se llamaba antes de super, así que al compilador no le molestaba.
• No soy desarrollador de Java, pero personalmente no me gusta mucho su sistema de import de módulos. Sintaxis como import * hace que escribir código sea fácil, pero leerlo sea mucho más difícil, especialmente para desarrolladores que no conocen el lenguaje o el codebase. C# y Nim también tienen ese estilo, y sin un IDE casi no puedo leerlos. Por eso prefiero ejemplos de alias cortos como en Python (import torch.nn.functional as F).
  • En codebases grandes, el principal problema de los import es “¿de dónde vino eso?”. Los import explícitos son imprescindibles, sobre todo cuando se rompe el build o hay confusión con versiones de dependencias. En codebases pequeñas, da igual lo que uses. Además, los editores modernos suelen ocultar los import, así que casi nunca los ves directamente; normalmente solo haces clic en el código o usas un atajo para ir a la definición, así que no les presto mucha atención.
  • Creo que si tu experiencia con C# no fue buena, es porque no usaste Visual Studio de verdad. VSCode está bien, pero nunca abriría archivos csproj o sln en VSCode. Por cierto, Visual Studio se puede comprar aquí por $500 con licencia perpetua, sin necesidad de una suscripción aparte.
  • No entiendo las quejas sobre construcciones del lenguaje que son difíciles de entender sin IDE. Si estás viendo el código en un IDE, no hay problema. Si alguien no usa IDE, se está causando esa incomodidad por su cuenta. Ver código en GitHub normalmente no implica analizar referencias en profundidad, así que ese nivel de incomodidad por brevedad me parece aceptable.
  • Hasta donde sé, este estilo está pensado para facilitar la escritura de programas de una sola fuente.
• Las nuevas funciones están bien resumidas en la página oficial de OpenJDK 25. Java 25 es una versión LTS.
  • Ojalá llegue pronto el día en que me toque migrar de 17 a 25 dentro de 10 años.
• Es una impresión personal, pero siento que, aunque Java es un lenguaje viejo, ha seguido evolucionando de forma constante en los últimos 10 años, mientras que C++ más bien se ha vuelto más difícil.
• Lamentablemente, structured concurrency todavía no se ha lanzado por completo. De verdad espero mucho esta función. En cambio, me da gusto la incorporación de Scoped Values; solo con eso ya siento que en Java se puede estructurar código con un estilo “rails-like” sin abusar de god-class o god-object.
  • Frente a la situación confusa de C++, donde se estandarizan funciones sin implementación actual, me parece mucho mejor el enfoque actual de Java de avanzar gradualmente con previews.
  • Espero que structured concurrency se sienta como un avance real y no como algo demasiado azucarado al estilo async/await. Viendo solo los ejemplos todavía no estoy convencido, pero pienso seguir observándolo.
• Hace poco decidí migrar desde JDK8 y me fui directo a JDK21. Como el 25 ya está a la vuelta de la esquina, elegí 21 en vez de pasar por 17. En mi opinión, lo más difícil fue migrar de 8 a 11, cuando apareció el nuevo sistema de módulos; después de eso me parece fácil. Hice la prueba de concepto en jdk17, y funcionó casi igual en jdk21 también, salvo que guice sí necesitó una actualización mayor. Por cierto, creo que también ayudó haber usado otro lenguaje de la JVM en vez de Java.
  • A nuestro equipo le costó migrar de 8 a 17. Usábamos mucho código no oficial, como los paquetes sun, y pasar de javax a jakarta también fue una carga. Pero una vez superada esa etapa, sentimos que ir a 21 o 25 es fácil. Espero que seguir versiones recientes de forma constante sea más llevadero que antes.
  • Java 9 fue el momento Python 3 del ecosistema, pero siento que ahora ya quedó resuelto sin problemas.
  • Para referencia, hace poco migré de 17 a 21 y no tuve ningún problema. Hubo detalles menores al actualizar Gradle junto con eso, pero en esencia es otro tema.
• Las funciones nuevas de Java 25 están bien resumidas en este post de baeldung.
• Me pregunto cuál es la situación actual de usar Java desde el punto de vista legal, tanto para código abierto como para uso comercial. Oracle mantiene tecnologías excelentes como Truffle atadas a Java, y quiero saber qué tan razonable es usarlo en proyectos nuevos.
  • OpenJDK es básicamente una versión con licencia abierta tomada directamente de Oracle. Si no te gusta Oracle, puedes usar versiones hechas por la Eclipse Foundation, Microsoft, Amazon y otros. Java tiene mucha longevidad, y por eso todavía se siguen usando versiones viejas como 8 y 11: una vez que lo escribes, realmente corre durante mucho tiempo. En funciones va más lento que sus competidores, pero para desarrollo importante es suficiente. Si dependes de la JVM, recomiendo Kotlin, sobre todo porque Java todavía no tiene tipos anulables y por eso NullPointerException sigue siendo común. Si no te gusta Kotlin, C# también está bien. Aun así, Java sigue siendo perfectamente utilizable.
  • A día de hoy, en el caso de la distribución de Oracle, básicamente solo puedes usar libremente la LTS más reciente. Las versiones inferiores tienen licencia OTN, así que solo sirven para uso personal o de desarrollo, no para producción. Si no necesitas específicamente la marca Oracle, OpenJDK o los JDK de otros proveedores no generan preocupaciones de licencia.
  • OpenJDK es completamente open source, así que no hay que preocuparse en absoluto.
  • Si usas algo como OpenJDK, te libras por completo del tema Oracle.
  • A menos que vayas a crear y distribuir tu propia implementación de Java, los temas legales casi no entran en consideración.