Después de seis meses de desarrollo, Oracle publicó la plataforma Java SE 26 (Java Platform, Standard Edition 26), de la cual se utiliza el proyecto OpenJDK como implementación de referencia. A excepción de la eliminación de algunas características obsoletas, Java SE 26 mantiene la compatibilidad hacia atrás con versiones anteriores de la plataforma Java; la mayoría de los proyectos Java previamente escritos funcionarán sin cambios al ejecutarse bajo la nueva versión. Las versiones listas para instalar de Java SE 26 (JDK, JRE y Server JRE) están disponibles para Linux (x86_64, AArch64), Windows (x86_64) y macOS (x86_64, AArch64). La implementación de referencia de Java SE 26 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 26 se clasifica como lanzamientos con un ciclo de soporte normal, cuyas actualizaciones se lanzarán hasta el próximo lanzamiento. Para una rama de soporte a largo plazo (LTS), se recomienda usar Java SE 25, Java SE 21 o Java SE 17, cuyas actualizaciones se lanzarán hasta 2033, 2031 y 2029 respectivamente (públicamente hasta septiembre de 2030, 2028 y 2026). El soporte extendido para la rama LTS de Java SE 8 se prolongará hasta 2030, y para Java SE 11 hasta 2032.
Entre los cambios en Java SE 26 (1, 2, 3, 4):
- Se implementó una advertencia al usar reflexión profunda para modificar campos marcados con la palabra clave 'final'. En el futuro, se planea desactivar por defecto las capacidades inseguras del lenguaje y, entre otras cosas, hacer que los campos marcados como final sean completamente inmutables, eliminando cualquier forma de modificarlos a través de reflexión profunda (API Reflection).
- Se eliminó la API Applet (java.applet.Applet*, javax.swing.JApplet), que se utilizaba para ejecutar aplicaciones Java en el navegador. Esta API perdió relevancia tras el cese del soporte para el complemento de Java en los navegadores y se declaró obsoleta en 2021.
- Se ha implementado la opción de utilizar caché preformado (AOT - ahead-of-time) con cualquier recolección de basura, incluido ZGC (Z Garbage Collector). Este cambio implica el soporte de la carga secuencial de objetos Java en la memoria, utilizando un formato universal y no dependiente de los recolectores de basura en lugar del mapeo directo en las representaciones de caché específicas en la memoria. El uso de caché AOT reduce el tiempo de arranque y acelera la fase de inicialización (warmup) de la máquina virtual HotSpot.
- Se ha añadido soporte para el protocolo HTTP/3 en la API del Cliente HTTP, lo que permite que aplicaciones y bibliotecas se conecten a servidores a través de HTTP/3 tras mínimos cambios en el código.
- Se ha mejorado el rendimiento del recolector de basura G1, gracias a la reducción de bloqueos para sincronizar los hilos de la aplicación con los hilos del recolector de basura.
- Se ha propuesto una segunda versión preliminar de la API para codificar y decodificar objetos con claves criptográficas, certificados y listas de revocación de certificados, utilizando el formato PEM (Pivacy-Enhanced Mail).
- Se ha propuesto para pruebas una sexta versión preliminar de la API para la concurrencia estructurada (Structured Concurrency), que simplifica el desarrollo de aplicaciones multihilo al tratar varias tareas que se ejecutan en diferentes hilos como un único bloque.
- Se ha añadido una segunda versión preliminar de la API Lazy Constants para trabajar con objetos que contienen datos inmutables y que son tratados en la JVM como constantes. A tales objetos se les aplican optimizaciones de rendimiento, similares a los campos con la palabra clave 'final'. A diferencia de 'final', la nueva API separa la creación de valores constantes de su inicialización, garantizando que el valor solo pueda ser inicializado una vez, reduciendo el tiempo de inicio de los programas y permitiendo aplicar en el código del usuario optimizaciones de plegado de constantes (constant-folding), que anteriormente solo se utilizaban en el código interno del JDK. class Application { // Antes: // static final UserService USERS = new UserService(); // Ahora se puede: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }
- En el mecanismo de coincidencia de patrones, se ha propuesto una cuarta opción 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 la instrucción «instanceof» y en los bloques «switch». switch (x.getStatus()) { case 0 -> «ok»; case 1 -> «advertencia»; case 2 -> «error»; case int i -> «estado desconocido: » + i; } if (i instanceof byte b) { … b … }
- Se ha propuesto una undécima implementación de prueba del API Vector, que proporciona funciones para cálculos vectoriales que se realizan utilizando instrucciones vectoriales de los procesadores x86_64 y AArch64, permitiendo realizar operaciones simultáneamente en varios valores (SIMD). A diferencia de las capacidades de autovectorización de operaciones escalares proporcionadas por el compilador JIT HotSpot, la nueva API permite un control explícito de la vectorización para el procesamiento paralelo de datos.
Además, Oracle ha anunciado el proyecto Detroit, que se desarrollará como parte de OpenJDK y que tiene como objetivo mejorar la portabilidad entre Java, JavaScript y Python. En el marco del proyecto, se pretende proporcionar la posibilidad de integrar en el proceso de ejecución de la JVM con el motor JavaScript V8 y el intérprete CPython. Anteriormente, Oracle había desarrollado el motor JavaScript Nashorn, que funcionaba sobre la máquina virtual JVM, pero se detuvo el proyecto debido a la dificultad de desarrollar una implementación separada de JavaScript en un contexto donde el ecosistema principal se basa en el motor V8.
Adicionalmente, se puede mencionar la publicación de la actualización de la plataforma para la creación de aplicaciones con interfaz gráfica JavaFX 26. En las próximas horas también se espera el lanzamiento de la máquina virtual universal GraalVM 26, que soporta la ejecución de aplicaciones en JavaScript (Node.js), Python, Ruby, R, y cualquier lenguaje para JVM (Java, Scala, Clojure, Kotlin), así como lenguajes que pueden generar código de bytes LLVM (C, C++, Rust).
Fuente: opennet.ru
