{"id":165062,"date":"2026-03-17T23:11:55","date_gmt":"2026-03-17T21:11:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm"},"modified":"2026-03-17T23:11:55","modified_gmt":"2026-03-17T21:11:55","slug":"vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm","title":{"rendered":"Lanzamiento de Java SE 26 y OpenJDK 26. Proyecto para la integraci\u00f3n de soporte de JavaScript y Python en la JVM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Despu\u00e9s de seis meses de desarrollo, Oracle ha publicado la plataforma Java SE 26 (Java Platform, Standard Edition 26), cuya implementaci\u00f3n de referencia es el proyecto abierto OpenJDK. A excepci\u00f3n de la eliminaci\u00f3n de algunas funciones obsoletas, Java SE 26 mantiene la compatibilidad hacia atr\u00e1s con versiones anteriores de la plataforma Java; la mayor\u00eda de los proyectos Java previamente escritos funcionar\u00e1n sin cambios al ejecutarse en la nueva versi\u00f3n. Se han preparado versiones listas para instalar de Java SE 26 (JDK, JRE y Server JRE) para Linux (x86_64, AArch64), Windows (x86_64) y macOS (x86_64, AArch64). La implementaci\u00f3n de referencia de Java SE 26, desarrollada dentro del proyecto OpenJDK, est\u00e1 completamente abierta bajo la licencia GPLv2 con excepciones de GNU ClassPath, que permiten el enlace din\u00e1mico con productos comerciales. <\/p>\n
Java SE 26 se clasifica como una versi\u00f3n con un ciclo de soporte est\u00e1ndar, y las actualizaciones se lanzar\u00e1n hasta la siguiente versi\u00f3n. Para la rama de soporte prolongado (LTS), se recomienda usar Java SE 25, Java SE 21 o Java SE 17, cuyas actualizaciones se lanzar\u00e1n hasta 2033, 2031 y 2029, respectivamente (p\u00fablicas hasta septiembre de 2030, 2028 y 2026). El soporte extendido para la rama LTS de Java SE 8 se prolongar\u00e1 hasta 2030, mientras que Java SE 11 lo har\u00e1 hasta 2032. <\/p>\n
Entre los cambios en Java SE 26 (1, 2, 3, 4): <\/p>\n
\n
Se ha implementado una advertencia al usar reflexi\u00f3n profunda para modificar campos marcados con la palabra clave \u00abfinal\u00bb. En el futuro, se planea deshabilitar por defecto las capacidades no seguras del lenguaje y, entre otras cosas, hacer que los campos marcados como final sean completamente inmutables, eliminando la forma de eludir esta restricci\u00f3n a trav\u00e9s de la reflexi\u00f3n profunda (API Reflection).\n
Se elimin\u00f3 la API Applet (java.applet.Applet*, javax.swing.JApplet), que se utilizaba para ejecutar aplicaciones Java en el navegador. Esta API perdi\u00f3 relevancia tras el cese del soporte para el complemento de Java en los navegadores y se declar\u00f3 obsoleta en 2021.\n
Se ha implementado la posibilidad de usar un cach\u00e9 precompilado (AOT - ahead-of-time) con cualquier recolector de basura, incluyendo ZGC (Z Garbage Collector). Este cambio implica el soporte para la carga secuencial de objetos Java cacheados en la memoria, utilizando un formato universal e independiente del recolector de basura en lugar de una mapeo directo a representaciones de cach\u00e9 espec\u00edficas. El uso del cach\u00e9 AOT reduce el tiempo de inicio y acelera la activaci\u00f3n (warmup) de la m\u00e1quina virtual HotSpot.\n
Se ha a\u00f1adido 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\u00e9s de HTTP\/3 tras m\u00ednimos cambios en el c\u00f3digo.\n
Se ha mejorado el rendimiento del recolector de basura G1, gracias a la reducci\u00f3n de bloqueos para sincronizar los hilos de la aplicaci\u00f3n con los hilos del recolector de basura.\n
Se ha propuesto una segunda versi\u00f3n preliminar de la API para codificar y decodificar objetos con claves criptogr\u00e1ficas, certificados y listas de revocaci\u00f3n de certificados, utilizando el formato PEM (Pivacy-Enhanced Mail).\n
Se ha propuesto para pruebas una sexta versi\u00f3n 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 \u00fanico bloque.\n
Se ha a\u00f1adido una segunda versi\u00f3n preliminar de la API Lazy Constants para trabajar con objetos que contienen datos inmutables y son tratados en la JVM como constantes. A estos objetos se les aplican optimizaciones de rendimiento similares a las de los campos con la palabra clave \u00abfinal\u00bb. A diferencia de \u00abfinal\u00bb, la nueva API separa la creaci\u00f3n de valores constantes de su inicializaci\u00f3n, garantiza que el valor solo puede ser inicializado una vez, reduce el tiempo de inicio de las aplicaciones y permite aplicar optimizaciones de plegado de constantes en el c\u00f3digo del usuario, que anteriormente solo se utilizaban en el c\u00f3digo interno del JDK. class Application { \/\/ Antes: \/\/ static final UserService USERS = new UserService(); \/\/ Ahora es posible: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }\n
En el mecanismo de coincidencia se ha propuesto una cuarta variante preliminar para la posibilidad de usar tipos primitivos (int, byte, char y otros tipos b\u00e1sicos que no son objetos) en todos los tipos de patrones, en el operador \u00abinstanceof\u00bb y en los bloques \u00abswitch\u00bb. switch (x.getStatus()) { case 0 -> \u00abokay\u00bb; case 1 -> \u00abwarning\u00bb; case 2 -> \u00aberror\u00bb; case int i -> \u00abunknown status: \u00bb + i; } if (i instanceof byte b) { \u2026 b \u2026 }\n
Se ha propuesto una und\u00e9cima implementaci\u00f3n de prueba del API Vector, que proporciona funciones para c\u00e1lculos vectoriales que se realizan utilizando instrucciones vectoriales de los procesadores x86_64 y AArch64, permitiendo realizar operaciones simult\u00e1neamente en varios valores (SIMD). A diferencia de las capacidades de autovectorizaci\u00f3n de operaciones escalares proporcionadas por el compilador JIT HotSpot, la nueva API permite un control expl\u00edcito de la vectorizaci\u00f3n para el procesamiento paralelo de datos. <\/ul>\n
Adem\u00e1s, Oracle ha anunciado el proyecto Detroit, que se desarrollar\u00e1 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\u00f3n de la JVM con el motor JavaScript V8 y el int\u00e9rprete CPython. Anteriormente, Oracle hab\u00eda desarrollado el motor JavaScript Nashorn, que funcionaba sobre la m\u00e1quina virtual JVM, pero se detuvo el proyecto debido a la dificultad de desarrollar una implementaci\u00f3n separada de JavaScript en un contexto donde el ecosistema principal se basa en el motor V8. <\/p>\n
Adicionalmente, se puede mencionar la publicaci\u00f3n de la actualizaci\u00f3n de la plataforma para la creaci\u00f3n de aplicaciones con interfaz gr\u00e1fica JavaFX 26. En las pr\u00f3ximas horas tambi\u00e9n se espera el lanzamiento de la m\u00e1quina virtual universal GraalVM 26, que soporta la ejecuci\u00f3n de aplicaciones en JavaScript (Node.js), Python, Ruby, R, y cualquier lenguaje para JVM (Java, Scala, Clojure, Kotlin), as\u00ed como lenguajes que pueden generar c\u00f3digo de bytes LLVM (C, C++, Rust). \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"