{"id":183379,"date":"2026-09-17T16:54:20","date_gmt":"2026-09-17T14:54:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/vypusk-java-se-27-i-openjdk-27"},"modified":"2026-09-17T16:54:25","modified_gmt":"2026-09-17T14:54:25","slug":"java-se-27-and-openjdk-27-released","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/java-se-27-and-openjdk-27-released","title":{"rendered":"Lanzamiento de Java SE 27 y OpenJDK 27","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Despu\u00e9s de seis meses de desarrollo, Oracle ha publicado la plataforma Java SE 27 (Java Platform, Standard Edition 27), cuyo proyecto de referencia es la iniciativa de c\u00f3digo abierto OpenJDK. A excepci\u00f3n de la eliminaci\u00f3n de algunas caracter\u00edsticas obsoletas, Java SE 27 mantiene la compatibilidad hacia atr\u00e1s con las versiones anteriores de la plataforma Java; la mayor\u00eda de los proyectos Java previamente escritos funcionar\u00e1n sin modificaciones con la nueva versi\u00f3n. Las versiones listas para instalar de Java SE 27 (JDK, JRE y Server JRE) est\u00e1n preparadas para Linux (x86_64, AArch64), Windows (x86_64) y macOS (x86_64, AArch64). La implementaci\u00f3n de referencia de Java SE 27, desarrollada bajo el proyecto OpenJDK, es completamente abierta bajo la licencia GPLv2 con excepciones de GNU ClassPath, que permiten el enlace din\u00e1mico con productos comerciales. <\/p>\n
Java SE 27 se clasifica como una versi\u00f3n con un ciclo de soporte habitual, con actualizaciones que se lanzar\u00e1n hasta la pr\u00f3xima versi\u00f3n. Se recomienda utilizar Java SE 25, Java SE 21 o Java SE 17 como versiones con soporte a largo plazo (LTS), cuya actualizaci\u00f3n se proporcionar\u00e1 hasta 2033, 2031 y 2029, respectivamente (p\u00fablicamente hasta septiembre de 2030, 2028 y 2026). El soporte extendido de 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 27 (1, 2, 3, 4): <\/p>\n
\n
Por defecto, se utiliza el recolector de basura G1 (Garbage-First) para todos los entornos, que anteriormente se aplicaba a sistemas de servidores. G1 est\u00e1 optimizado para su uso en sistemas multiprocesador con gran cantidad de memoria y equilibra la predictibilidad de latencias con alta capacidad de procesamiento. Durante su funcionamiento, G1 divide la memoria en muchas regiones peque\u00f1as y limpia primero aquellas regiones donde hay m\u00e1s objetos no utilizados y menos datos activamente utilizados.\n
En la JVM HotSpot, se utilizan por defecto encabezados compactos de objetos. El tama\u00f1o de los encabezados en sistemas de 64 bits se ha reducido de 96 a 64 bits, lo que ha disminuido el consumo de memoria y ha aumentado la probabilidad de que los datos se almacenen en la cach\u00e9 del procesador. En las pruebas SPECjbb2015, el consumo de memoria se redujo en un 22%, la carga en el CPU disminuy\u00f3 en un 8%, y el n\u00famero de operaciones de recolecci\u00f3n de basura se redujo en un 15%. Al probar el analizador JSON, el tiempo de ejecuci\u00f3n de las pruebas se redujo en un 10%.\n
La implementaci\u00f3n de TLS 1.3 ahora incluye soporte para esquemas de negociaci\u00f3n de claves h\u00edbridos, combinando el algoritmo ML-KEM (CRYSTALS-Kyber), resistente a ataques de computadoras cu\u00e1nticas, con algoritmos cl\u00e1sicos basados en curvas el\u00edpticas ECDHE: X25519MLKEM768 (ECDHE con curva X25519 + ML-KEM-768), SecP256r1MLKEM76 (ECDHE con curva secp256r1 + ML-KEM-768) y SecP384r1MLKEM1024 (ECDHE con curva secp384r1 + ML-KEM-1024). En la API javax.net.ssl<\/a> Estos esquemas est\u00e1n habilitados por defecto y no requieren modificaciones en las aplicaciones para ser utilizados.\n