Lanzamiento de Java SE 24 y OpenJDK 24

Después de seis meses de desarrollo, Oracle ha publicado la plataforma Java SE 24 (Java Platform, Standard Edition 24), cuya implementación de referencia utiliza el proyecto abierto OpenJDK. Excepto por la eliminación de algunas funcionalidades obsoletas, Java SE 24 mantiene la compatibilidad hacia atrás con versiones anteriores de la plataforma Java: la mayoría de los proyectos Java previamente desarrollados funcionarán sin cambios al ejecutarse bajo la nueva versión. Las distribuciones listas para instalar de Java SE 24 (JDK, JRE y Server JRE) están preparadas para Linux (x86_64, AArch64), Windows (x86_64) y macOS (x86_64, AArch64). La implementación de referencia de Java SE 24 desarrollada en el marco del proyecto OpenJDK está completamente abierta bajo la licencia GPLv2 con excepciones de GNU ClassPath que permiten el enlace dinámico con productos comerciales.

Java SE 24 se clasifica como una versión con un ciclo de soporte regular, y las actualizaciones se lanzarán hasta el siguiente lanzamiento. Como rama de soporte a largo plazo (LTS), se deben usar Java SE 21 o Java SE 17, cuyas actualizaciones se lanzarán hasta 2031 y 2029 respectivamente (las versiones públicas hasta 2028 y 2026). El soporte extendido de la rama LTS de Java SE 8 se prolongará hasta 2030, y Java SE 11 hasta 2032. La próxima versión LTS será el lanzamiento de otoño de Java SE 25.

Entre las novedades propuestas en Java SE 24 están:

• Se ha propuesto un modo generativo experimental para el recolector de basura Shenandoah, en el que se procesan por separado los objetos antiguos y los recién creados para mejorar la eficiencia de recolección de objetos con poco tiempo de vida. Este nuevo modo proporciona una capacidad de procesamiento más predecible, resistencia a cambios de carga y una reducción en el consumo de memoria durante la recolección de basura. El planificador de Shenandoah está diseñado para reducir el tiempo de interrupciones durante la recolección de basura al realizar una mayor cantidad de trabajo en paralelo con la ejecución de aplicaciones Java.
• En HotSpot JVM se ha implementado soporte experimental para encabezados compactos de objetos, cuyo tamaño en sistemas de 64 bits se ha reducido de 96 a 64 bits (de 12 a 8 bytes). La reducción del tamaño de los encabezados permite disminuir el tamaño del montón y aumentar la eficiencia del caché.
• En el recolector de basura G1, se ha simplificado la implementación de barreras que rastrean el acceso de la aplicación a la memoria. En la nueva versión, las operaciones de expansión de barreras se han trasladado a una etapa posterior en la compilación en el JIT C2. Las pruebas realizadas muestran que este traslado permite reducir los costos generales en el compilador JIT C2 entre un 10% y un 20% dependiendo de la aplicación.
• Se ha añadido una API para utilizar funciones criptográficas de derivación de claves (KDF, key derivation function), que permiten generar claves adicionales de la longitud necesaria basadas en una clave secreta (por ejemplo, una contraseña) y un conjunto de datos aleatorios. La API de KDF todavía tiene el estatus de preliminar (preview).
• Se ha añadido la posibilidad de carga y agrupación de clases anticipada (Ahead-of-Time). Este cambio permite acelerar el inicio de la JVM HotSpot al proporcionar las clases utilizadas en la aplicación en un estado ya cargado y agrupado. Durante el primer inicio de la aplicación, el estado de todas las clases se guarda en caché y en los siguientes inicios se utiliza para acelerar la carga.
• Se ha añadido la API Class-File para analizar, generar y transformar archivos con clases Java.

  ClassFile cf = ClassFile.of(); ClassModel classModel = cf.parse(bytes); byte[] newBytes = cf.build(classModel.thisClass().asSymbol(), classBuilder -> { for (ClassElement ce : classModel) { if (!(ce instanceof MethodModel mm && mm.methodName().stringValue().startsWith("debug"))) { classBuilder.with(ce); } } });

• Se ha añadido una API Stream mejorada, que admite la definición de operaciones intermedias personalizadas, útiles en casos donde las operaciones intermedias integradas existentes son insuficientes para la transformación de datos deseada. Los manejadores personalizados se conectan mediante una nueva operación intermedia Stream::gather(Gatherer), que procesa los elementos del flujo aplicando el manejador proporcionado por el usuario. jshell > Stream.of(1,2,3,4,5,6,7,8,9).gather(new WindowFixed(3)).toList() $1 == > [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
• Se ha propuesto una cuarta implementación preliminar de los Valores Acotados (Scoped Values), que permite compartir datos inmutables entre hilos y facilitar el intercambio de datos entre sub-hilos (los valores se heredan). Los Valores Acotados se están desarrollando para reemplazar el mecanismo de variables locales de hilo (thread-local variables) y son más eficientes cuando se utilizan un número muy grande de hilos virtuales (miles y millones de hilos). La principal diferencia entre Scoped Values y las variables locales de hilo es que los primeros se escriben una vez, no se pueden modificar y quedan disponibles solo durante la ejecución del hilo.
• Se ha añadido soporte preliminar para el uso de tipos primitivos (int, byte, char y otros tipos básicos que no son objetos) en todos los tipos de plantillas, en el operador «instanceof» y en los bloques «switch». switch (x.getStatus()) { case 0 -> «okay»; case 1 -> «warning»; case 2 -> «error»; case int i -> «unknown status: » + i; } if (i instanceof byte b) { … b … }
• Se ha propuesto la novena implementación preliminar de la API Vector, que proporciona funciones para cálculos vectoriales que se ejecutan utilizando instrucciones vectoriales de los procesadores x86_64 y AArch64 y permiten aplicar operaciones a varios valores simultáneamente (SIMD). A diferencia de las capacidades de auto-vectorización de operaciones escalares proporcionadas en el compilador JIT HotSpot, la nueva API permite gestionar explícitamente la vectorización para el procesamiento paralelo de datos.
• Se ha implementado el soporte para la sincronización de hilos virtuales sin vincularlos (pinning) a hilos asociados con la plataforma. Los hilos virtuales en un método o expresión sincronizada en estado de bloqueo ahora liberan su hilo de plataforma, permitiendo que otros hilos virtuales lo utilicen, lo que incrementa significativamente la cantidad de hilos virtuales disponibles y mejora la escalabilidad de las aplicaciones que utilizan múltiples hilos.
• Se ha añadido una tercera opción preliminar que permite especificar expresiones en constructores antes de la llamada a super(…), utilizada para invocar explícitamente el constructor de la clase padre desde el constructor de la clase heredada, si estas expresiones no se refieren a la instancia de constructor que se está creando. class Outer { void hello() { System.out.println("Hello"); } class Inner { Inner() { hello(); super(); } } }
• La utilidad jlink ha implementado soporte para crear imágenes de tiempo de ejecución sin utilizar archivos JMOD, lo que permite reducir el tamaño del JDK en aproximadamente un 25%.
• Se ha añadido una segunda opción preliminar para el uso de una expresión "import module M" para importar todos los paquetes exportados por el módulo especificado de una sola vez. Este cambio simplifica considerablemente la reutilización de bibliotecas modulares, permitiendo conectar bibliotecas y clases sin necesidad de definir su ubicación en la jerarquía de paquetes. Por ejemplo, especificar "import module java.base" resultará en la importación de los 54 paquetes del módulo java.base, que antes tendrían que haberse mencionado por separado ("import java.io.*", "import java.util.*", etc.).
• Se ha añadido una cuarta implementación preliminar de clases declaradas implícitamente y de instancias anónimas del método "main", donde se puede prescindir de las declaraciones public/static, de pasar un array de argumentos y de otras entidades relacionadas con la declaración de la clase. // antes public class HelloWorld { public static void main(String[] args) { System.out.println("¡Hola mundo!"); } } // ahora se puede void main() { System.out.println("¡Hola, Mundo!"); }
• Se ha propuesto para pruebas una cuarta opción preliminar de la API para el paralelismo estructurado (Structured Concurrency), que simplifica el desarrollo de aplicaciones multihilo al tratar varias tareas que se ejecutan en diferentes hilos como un único bloque.
• En la API KeyPairGenerator, Signature y KeyFactory se ha añadido soporte para los algoritmos ML-KEM (CRYSTALS-Kyber) y ML-DSA (CRYSTALS-Dilithium), estandarizados por el Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST) y resistentes a la factorización en computadoras cuánticas. Estos algoritmos utilizan métodos de criptografía basados en la resolución de problemas de teoría de redes, cuyo tiempo de resolución no difiere en computadoras convencionales y cuánticas.
• En el recolector de basura ZGC se ha eliminado el soporte para el modo de operación no generativo, que no separa el manejo de los objetos "viejos" y "nuevos". A partir de Java SE 23, el modo generativo de ZGC se aplica por defecto.
• Se han añadido advertencias sobre el uso de la API JNI (Java Native Interface) y FFM (Foreign Function & Memory) para preparar a los desarrolladores para la restricción de acceso a estas APIs debido a la inclusión del modo de integridad en futuras versiones, que prohíbe por defecto la interacción con código nativo.
• Se ha activado una advertencia al utilizar métodos de acceso a memoria externa (fuera de la JVM) proporcionados por la clase sun.misc.Unsafe. Para acceder a la memoria fuera del montón (off-heap) e interactuar con código externo, se recomienda usar la API VarHandle. En la versión anterior, el soporte para sun.misc.Unsafe fue declarado obsoleto.
• Se ha desactivado el Security Manager, que ha perdido relevancia y se ha vuelto innecesario tras el cese del soporte para el complemento del navegador. El Security Manager fue clasificado como obsoleto en Java 17. Se planea eliminar completamente el código del Security Manager en futuras versiones.
• Se ha eliminado el código que soportaba la plataforma de 32 bits de Windows en sistemas x86. El puerto de Java para sistemas x86 de 32 bits ha sido declarado obsoleto y está programado para eliminación (se suspenderá el soporte para Linux en sistemas de 32 bits x86).

Además, se destacó la publicación de una actualización de la plataforma para crear aplicaciones con interfaz gráfica JavaFX 24 y el nuevo lanzamiento de la máquina virtual universal GraalVM, que soporta la ejecución de aplicaciones en JavaScript (Node.js), Python, Ruby, R, cualquier lenguaje para JVM (Java, Scala, Clojure, Kotlin) y lenguajes para los cuales se puede generar código de bytes LLVM (C, C++, Rust). Además del soporte para JDK 24, la nueva versión de GraalVM ha optimizado tareas relacionadas con el aprendizaje automático, mejorado la compilación de código de bytes Java a código máquina, y añadido un mecanismo SkipFlow para reducir el tamaño de los archivos ejecutables y disminuir el tiempo de compilación.

Fuente: opennet.ru