Cambios de la versión Java 8

Características principales de la versión Java 8

Este artículo se aplica a:

Plataformas: Ninguno
Exploradores: Ninguno
Versiones de Java: 8.0

Esta página resalta los cambios que afectan a los usuarios finales en cada versión de Java. Para obtener más información acerca de los cambios, consulte las notas técnicas sobre la versión para cada versión.
» Fechas de publicación de Java

Java 8 Update 441 (8u441)

Características principales de la versión

JDK 8u441 contiene datos de la zona horaria de IANA 2024a .
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
JavaFX Will dejará de incluirse en JDK/JRE 8
Esta versión, la actualización 441 de JDK y JRE 8, es la última versión en incluir JavaFX. De acuerdo al anuncio de 2020, JavaFX en JDK 8, la última versión soportada de JavaFX de Oracle, dejará de estar soportada en marzo de 2025. Por lo tanto, la actualización 441 de JDK 8 es la última versión de JDK/JRE 8 con JavaFX. Oracle seguirá desarrollando y publicando módulos independientes de JavaFX a través del proyecto OpenJFX, solo para las últimas versiones de Java. Para obtener más información, consulte la actualización de la hoja de ruta de Java SE de la primavera de 2024.
Otras notas: Soporte para Time Zone Database 2024b
IANA Time Zone Database se ha actualizado a 2024b. Esta versión incluye cambios para mejorar el historial de datos de México, Mongolia y Portugal. También cambia una abreviatura del registro de hora de la zona horaria 'MET'. Asimismo, Asia/Choibalsan es el nuevo alias para Asia/Ulaanbaatar.
Consulte JDK-8339637

Actualización de JDK

Oracle recomienda que se actualice el JDK con cada actualización de parche crítico. Para determinar si una versión es la más reciente, la página de Security Baseline se puede utilizar para determinar cuál es la versión más reciente de cada familia de versiones.

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda utilizar este JDK (versión 8u441) después de la próxima actualización de parche crítico programada para el 15 de abril de 2025.

Java Management Service, a disposición de todos los usuarios, puede ayudarle a encontrar versiones de Java vulnerables en sus sistemas. Los suscriptores de Java SE y los clientes que se ejecuten en Oracle Cloud pueden utilizar Java Management Service para actualizar Java Runtime Environment y llevar a cabo más revisiones de seguridad, como identificar bibliotecas de terceros potencialmente vulnerables que usen sus programas de Java. Los usuarios existentes de Java Management Service pueden hacer clic aquí para conectarse a su panel de control. En la documentación de Java Management Service hay una lista de funciones disponibles para todo el mundo, así como aquellas que solo están disponibles para clientes. Obtenga más información sobre el uso de Java Management Service para supervisar y proteger sus instalaciones de Java.

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u441) el 15 de mayo de 2025. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

Esta versión contiene correcciones para las vulnerabilidades de seguridad descritas en el Aviso de actualización de parche crítico de Oracle. Para acceder a una lista más completa de las correcciones de bugs que incluye esta versión, consulte Notas de la versión 8u441.

Java 8 Update 431 (8u431)

Características principales de la versión

JDK 8u431 contiene datos de la zona horaria de IANA 2024a .
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Problemas notables resueltos: La actualización del RPM de JDK deja entradas alternativas huérfanas
Problema corregido con las entradas en los grupos "java" y "javac" que no se habían gestionado correctamente durante una actualización del RPM.
Cambio de un RPM de Java instalado más antiguo en un directorio compartido (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}) a un RPM de Java que se instala en la versión específica de un directorio (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}), que provoca que las entradas de Java más antiguas en los grupos "java" y "javac" no se supriman.
JDK-8336107 (no público)
Otras notas: Nuevos límites por defecto en las implementaciones de HTTP de JDK
Se han agregado nuevos límites por defecto a HTTP en JDK.
La implementación integrada de JDK del manejador del protocolo de URL para HTTP (HttpURLConnection) tiene ahora un límite por defecto para el tamaño máximo de las cabeceras de respuesta que se aceptará de una parte remota. El límite se ha definido en 384 kB (393 216 bytes) y se calcula a partir del tamaño acumulado de todos los nombres y valores de las cabeceras más una sobrecarga de 32 bytes por cada par de valores de nombre de cabeceras.
JDK-8328286 (no público)
Otras notas: Se han agregado los certificados raíz TLS de la CA SSL.com emitidos en 2022
Se han agregado los siguientes certificados raíz al almacén de confianza cacerts:
+ SSL.com
+ ssltlsrootecc2022
DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US
+ SSL.com
+ ssltlsrootrsa2022
DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US
Consulte JDK-8341057
Otras notas:Eliminación de certificados de servidor TLS fijados por los certificados raíz de Entrust y emitidos después del 11 de noviembre de 2024
JDK dejará de confiar en los certificados de servidor TLS emitidos después del 11 de noviembre de 2024 y fijados por los certificados raíz de Entrust, de conformidad con planes similares anunciados recientemente por Google y Mozilla. En la lista de certificados afectados se incluyen algunos con la marca AffirmTrust, gestionados por Entrust.
Consulte JDK-8337664

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda que este JDK (versión 8u431) se utilice después de la próxima actualización de parche crítico programada para el 21 de enero de 2025.

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u431) el 21 de febrero de 2025. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

Java 8 Update 421 (8u421)

Características principales de la versión

JDK 8u421 contiene datos de la zona horaria de IANA 2024a .
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Problema conocido: Uso del almacén de claves del explorador en Windows
En Windows, una vez que la función "Usar los certificados y claves del almacén de claves del explorador" está activada (que lo está por defecto), Java WebStart y Java Plugin pueden acceder a los certificados de confianza de la máquina local. No hay garantía de que esté disponible la lista completa de certificados de confianza, ya que estos se cargan de forma dinámica. Como resultado, los subprogramas de Java y las aplicaciones Java WebStart pueden tener problemas de validación de firmas y de conexión segura porque no hay certificados relevantes, ya que el marco de despliegue solo puede acceder a los certificados que están 'activos' en el momento de inicio de la aplicación.
JDK-8330728 (no público)
Otras notas: Adición del argumento STATIC=1 al instalador de JRE
Esta corrección agregará el argumento STATIC=1 al instalador y dejará de usar el argumento RETAIN_ALL_VERSIONS=1 en el instalador. Al transferir STATIC=1, se protegerán las versiones de JRE 8 más antiguas y no se desinstalarán durante un cambio de versión manual ni automático.
JDK-8313223 (no público)
Otras notas: Se han agregado los certificados de CA GlobalSign R46 y E46 raíz
Los siguientes certificados raíz se han agregado al almacén de confianza cacerts:
+ GlobalSign + globalsignr46 DN: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE + GlobalSign + globalsigne46 DN: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE
Consulte JDK-8316138
Otras notas: El instalador creará un directorio de unión en una nueva ubicación
El JRE se instalará en la siguiente ubicación, C:\Program Files\Java\latest\jre-$fullversion, donde $fullversion es la versión técnica del JRE. Por ejemplo, la versión 8u421 se instalará en C:\Program Files\Java\latest\jre-1.8.0_421.

"C:\Program Files" se ajustará a "C:\Program Files (x86)" para los entornos Java de 32 bits.

Se creará una unión en C:\Program Files\Java\latest\jre-1.8. Apuntará al JRE más reciente de la familia 8.
JDK-8329700 (no público)

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda utilizar este JDK (versión 8u421) después de la próxima actualización de parche crítico programada para el 15 de octubre de 2024.

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (8u421) el 15 de noviembre de 2024. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

Java 8 Update 411 (8u411)

Características principales de la versión

JDK 8u411 contiene datos de la zona horaria de IANA 2024a .
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Adición de los certificados Certainly R1 y raíz E1
Se han agregado los siguientes certificados raíz al almacén de confianza cacerts:+ Certainly + certainlyrootr1 DN: CN=Certainly Root R1, O=Certainly, C=US + Certainly + certainlyroote1 DN: CN=Certainly Root E1, O=Certainly, C=US
Consulte JDK-8321408
Nueva función: Activación del modo de validación seguro de firma XML por defecto
El modo de validación seguro de firma XML se ha activado por defecto (antes no se activaba por defecto a menos que se ejecutara con un gestor de seguridad). Cuando se activa, la validación de las firmas XML está sujeta a una comprobación más estricta de los algoritmos y otras restricciones como se especifica en la propiedad de seguridad jdk.xml.dsig.secureValidationPolicy.
De ser necesario, y bajo su responsabilidad, las aplicaciones pueden desactivar el modo estableciendo la propiedad org.jcp.xml.dsig.secureValidation como Boolean.FALSE con la API DOMValidateContext.setProperty().
Consulte JDK-8259801

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda que este JDK (versión 8u411) se utilice después de la próxima actualización de parche crítico programada para el 16 de julio de 2024.

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (8u411) el 16 de agosto de 2024. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

Java 8 Update 401 (8u401)

Características principales de la versión

JDK 8u401 contiene datos de la zona horaria de IANA 2023c.
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Nueva propiedad del sistema para conmutar el modo de validación seguro de firma XML
Se ha agregado una nueva propiedad del sistema denominada org.jcp.xml.dsig.secureValidation. Se puede utilizar para activar o desactivar el modo de validación seguro de firma XML. La propiedad del sistema se debe definir en "true" para activarla, o en "false" para desactivarla. Cualquier otro valor para la propiedad del sistema se trata como "false". Si está definida la propiedad del sistema, esta sustituye el valor de propiedad XMLCryptoContext. El modo de validación seguro se activa por defecto si ejecuta el código con un SecurityManager. De lo contrario, se desactiva por defecto.
Consulte el JDK-8301260
Nueva función: Evento de grabador en ejecución de JDK para la deserialización
Se ha agregado un nuevo evento de grabador en ejecución de JDK (JFR) para supervisar la deserialización de objetos. Si JFR está activado y la configuración de JFR incluye eventos de deserialización, JFR emitirá un evento siempre que el programa en ejecución intente deserializar un objeto. El evento de deserialización se denomina java/deserialization y está desactivado por defecto. El evento de deserialización contiene información que se utiliza en el mecanismo de filtro de deserialización. Además, si un filtro está activado, el evento de JFR indica si el filtro ha aceptado o rechazado la deserialización del objeto.
Consulte el JDK-8261160

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda utilizar este JDK (versión 8u401) después de la próxima actualización de parche crítico programada para el 16 de abril de 2024.

Los clientes con productos de Java SE Subscription que gestionan actualizaciones/instalaciones para un gran número de escritorios, deberían considerar el uso de Java Management Service (JMS).

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (8u401) el 16 de mayo de 2024. Cuando se haya cumplido una de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará advertencias y recordatorios adicionales de actualización a la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

Java 8 Update 391 (8u391)

Características principales de la versión

JDK 8u391 contiene datos de la zona horaria de IANA 2023c.
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Nuevo evento de JFR: jdk.SecurityProviderService
Se ha agregado un nuevo evento de Java Flight Recorder (JFR) para registrar los detalles de las llamadas de java.security.Provider.getService(String type, String algorithm).
Consulte JDK-8254711
Función eliminada: Certificado raíz RootCA1 de SECOM Trust System eliminado
El siguiente certificado raíz de SECOM Trust System se ha eliminado del almacén de claves cacerts:
+ alias name "secomscrootca1 [jdk]" Distinguished Name: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
Consulte JDK-8295894
Función eliminada: Eliminación del soporte de Linux ARM32 para JDK 8
Se ha eliminado el soporte de la plataforma Linux ARM32 en JDK 8. Como resultado, la descarga de ARM32 Hard Float ABI dejará de estar disponible. El sistema operativo que soportaba ARM32 ha alcanzado su fin de vida, por lo que no hay ningún soporte de sistema operativo conocido disponible.
JDK-8305927 (no público)
Otras notas: Se ha agregado el certificado de CA raíz Certigna
Se ha agregado el siguiente certificado raíz al almacén de confianza cacerts:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR
Consulte JDK-8314960

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda que este JDK (versión 8u391) se utilice después de la próxima actualización de parche crítico programada para el 16 de enero de 2024.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u391) el 16 de febrero de 2024. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para obtener más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía Java Platform, Standard Edition Deployment Guide.

Correcciones de bugs

Java 8 Update 381 (8u381)

Características principales de la versión

JDK 8u381 contiene datos de la zona horaria de IANA 2023c.
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Permitir caracteres adicionales para soportar GB18030-2022
El organismo nacional de estandarización chino (CESI) ha publicado recientemente GB18030-2022, una versión actualizada del estándar GB18030 que sincroniza GB18030 con la versión 11.0 de Unicode. La implementación del juego de caracteres de este nuevo estándar ha sustituido al anterior estándar 2000. Sin embargo, este nuevo estándar tiene algunos cambios incompatibles procedentes de la implantación anterior. Se ha introducido una nueva propiedad del sistema, jdk.charset.GB18030, para aquellos que necesiten utilizar las antiguas asignaciones. Al definir el valor en 2000, se utilizarán las asignaciones anteriores de JDK para el juego de caracteres de GB18030, basadas en el estándar 2000.
Consulte JDK-8307229
JDK ahora acepta claves RSA en formato PKCS#1
Los proveedores de JDK ahora pueden aceptar claves RSA públicas y privadas en formato PKCS#1, como la RSA KeyFactory.impl del proveedor SunRsaSign. El objeto de clave RSA pública y privada debe tener el formato PKCS#1 o una codificación que coincida con la sintaxis ASN.1 para una clave RSA PKCS#1 pública y privada.
Consulte JDK-8023980
Otras notas: Soporte de cgroup v2 y mejoras en 8u381
JDK 8u381 incluye varias mejoras y correcciones para mejorar el soporte de cgroup v1 y v2 para contenedores. Las mejoras incluyen: detectar de manera precisa los límites de recursos de los contenedores, informar correctamente acerca de las métricas de contenedores recogidas, imprimir información adicional sobre estos y mejorar la estabilidad de las aplicaciones en entornos de contenedor.
Consulte JDK-8307634
Otras notas: Se ha agregado el certificado de CA raíz TWCA
Se ha agregado el siguiente certificado raíz al almacén de confianza cacerts:
+ TWCA + twcaglobalrootca DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW
Consulte JDK-8305975
Otras notas: Se han añadido 4 certificados de CA raíz GTS
Se han agregado los siguientes certificados raíz al almacén de confianza cacerts:
+ Google Trust Services LLC + gtsrootcar1 DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootcar2 DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar3 DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar4 DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US
ConsulteJDK-8307134
Otras notas: Se han agregado 2 certificados de CA raíz TLS de Microsoft Corporation
Se han agregado los siguientes certificados raíz al almacén de confianza cacerts:
+ Microsoft Corporation + microsoftecc2017 DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US + Microsoft Corporation + microsoftrsa2017 DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US
Consulte JDK-8304760

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda utilizar este JDK (versión 8u381) después de la próxima actualización de parche crítico programada para el 17 de octubre de 2023.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u381) el 17 de noviembre de 2023. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

Java 8 Update 371 (8u371)

Características principales de la versión

JDK 8u371 contiene datos de la zona horaria de IANA 2022g.
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Se ha agregado una biblioteca de GSS-API nativa por defecto en Windows
Se ha agregado una biblioteca de GSS-API nativa al JDK en la plataforma Windows. La biblioteca es solo del cliente y utiliza las credenciales por defecto. Se cargará cuando la propiedad sun.security.jgss.native del sistema esté definida en "true". El usuario puede cargar una biblioteca de GSS-API nativa de terceros definiendo la propiedad sun.security.jgss.lib del sistema en su ruta.
Consulte JDK-6722928
Funciones y opciones eliminadas: Las implementaciones del motor javax.script y com.apple.concurrent.Dispatch se han eliminado para macOS AArch64
El motor de AppleScript que implementaba la API del motor javax.script se ha eliminado y no se ha proporcionado ningún reemplazo. El motor de AppleScript ha funcionado de manera inconsistente. Faltaba el archivo de configuración de los servicios (META-INF/services) y solo funcionaba por accidente al instalar el JDK 7 o JDK 8 en sistemas que ya tenían la versión de Apple de AppleScriptEngine.jar en el sistema.
La API com.apple.concurrent.Dispatch era una API solo de Mac. Se pasó al JDK 7u4 con el puerto del código del JDK 6 de Apple. En vez de eso, se recomienda a los desarrolladores que utilicen las API estándar java.util.concurrent.Executor y java.util.concurrent.ExecutorService.
Consulte JDK-8297475
Otras notas: Se ha agregado el certificado de CA raíz Certigna(Dhimyotis)
Se ha agregado el siguiente certificado raíz al almacén de confianza cacerts:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna, O=Dhimyotis, C=FR
Consulte JDK-8245654
Otras notas: Se han eliminado SSLv2Hello y SSLv3 de los protocolos de TLS activados por defecto
Se han eliminado SSLv2Hello y SSLv3 de los protocolos de TLS activados por defecto.

Después de esta actualización, si se ha eliminado SSLv3 de la propiedad de seguridad jdk.tls.disabledAlgorithms, las API SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() y SSLParameters.getProtocols() devolverán "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". No se devolverá "SSLv3" en esta lista.
Si un cliente o servidor tiene que utilizar el protocolo SSLv3, puede hacerlo activándolo en las propiedades jdk.tls.client.protocols o jdk.tls.server.protocols del sistema o con las API SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() y SSLEngine.setEnabledProtocols().
Consulte JDK-8190492

Actualización de JDK

Oracle recomienda que se actualice el JDK con cada actualización de parche crítico. Consulte la página Línea base de seguridad para determinar la versión más reciente para cada familia de versiones.

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se anuncian con un año de antelación en la sección Critical Patch Updates, Security Alerts and Bulletins. No se recomienda utilizar este JDK (versión 8u371) después de la próxima actualización de parche crítico programada para el 18 de julio de 2023.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u371) el 18 de agosto de 2023. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

Java 8 Update 361 (8u361)

Características principales de la versión

JDK 8u361 contiene datos de la zona horaria de IANA 2022d, 2022e y 2022f.
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: soporte para RSASSA-PSS en la respuesta de OCSP
La respuesta de OCSP firmada con un algoritmo RSASSA-PSS ya está soportada.
Consulte JDK-8274471
Otras notas: el motor de JavaScript de FXML está desactivado por defecto
El “motor de scripts de JavaScript” para FXML ahora estará desactivado por defecto. Cualquier archivo .fxml con una instrucción de procesamiento (PI) "javascript" ya no se cargará por defecto y devolverá una excepción.
Se puede activar mediante la configuración de la propiedad: -Djavafx.allowjs=true
JDK-8294779 (no pública)
Otras notas: no se han manipulado correctamente los argumentos entre comillas en ProcessBuilder
ProcessBuilder en Windows se ha restaurado para hacer referencia a una regresión debido a JDK-8250568. Antes, un argumento de ProcessBuilder que empezara con comillas dobles y terminara con una barra invertida seguida de comillas dobles se enviaba, de forma incorrecta, a un comando y podía hacer que se produjera un fallo. Por ejemplo, el comando percibiría el argumento "C:\\Program Files\" con unas comillas dobles extra. En esta actualización se restaura el antiguo comportamiento que no trata de forma especial la barra invertida antes de las comillas dobles de cierre.
Consulte JDK-8282008
Otras notas: hacer configurable el timeout de mantenimiento de conexiones por defecto de HttpURLConnection
Se han añadido dos propiedades de sistema que controlan el comportamiento de mantenimiento de conexiones de HttpURLConnection cuando no se ha especificado una hora de mantenimiento de conexiones en el servidor. Se han definido dos propiedades para controlar las conexiones a servidores y proxies de forma independiente. Son http.keepAlive.time.server y http.keepAlive.time.proxy, respectivamente. Puede obtener más información sobre estas propiedades en Propiedades de red.
ConsulteJDK-8278067
Otras notas: la herramienta VisualVM ya no está incluida
Esta versión de JDK ya no incluirá una copia de Java VisualVM. VisualVM se puede descargar ahora de forma independiente en https://visualvm.github.io.
ConsulteJDK-8294184

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda que este JDK (versión 8u361) se utilice después de la próxima actualización de parche crítico programada para el 18 de abril de 2023.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u361) el 18 de mayo de 2023. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

Java 8 Update 351 (8u351)

Características principales de la versión

Datos de la zona horaria de IANA 2022b, 2022c..
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Otras notas: Se ha cambiado la versión del algoritmo MAC por defecto para PKCS12
Se ha actualizado el algoritmo MAC por defecto que se utiliza en los almacenes de claves PKCS #12. El nuevo algoritmo está basado en SHA-256 y es más seguro que el algoritmo anterior basado en SHA-1. Consulte las propiedades de seguridad que empiezan por keystore.pkcs12 en el archivo java.security para obtener información detallada.
Consulte JDK-8267880
Otras notas: Se han desactivado los JAR firmados con SHA-1
Los JAR firmados con algoritmos SHA-1 se restringen ahora por defecto y se tratan como si no estuvieran firmados. Esto se aplica a los algoritmos utilizados para resumir, firmar y, de forma opcional, registrar la hora del JAR. También se aplica a los algoritmos de firma y resumen de los certificados en la cadena de certificados del firmante del código y la autoridad de registro de hora, así como a cualquier respuesta de OCSP o CRL que se utilice para verificar si dichos certificados se han revocado. Estas restricciones también se aplican a los proveedores de JCE firmados.
Consulte JDK-8269039
Otras notas: Se ha dejado de utilizar 3DES y RC4 en Kerberos
Los tipos de cifrado de Kerberos (etypes) des3-hmac-sha1 y rc4-hmac han quedado ahora en desuso y están desactivados por defecto. Los usuarios pueden definir allow_weak_crypto = true en el archivo de configuración krb5.conf para volver a activarlos (así como otros etypes poco seguros entre los que se incluyen des-cbc-crc y des-cbc-md5) bajo su propio riesgo. Para desactivar un subjuego de los etypes poco seguros, los usuarios pueden indicar explícitamente los etypes que prefieren en cualquiera de los valores default_tkt_enctypes, default_tgs_enctypes o permitted_enctypes.
Consulte JDK-8139348

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda que este JDK (versión 8u351) se utilice después de la próxima actualización de parche crítico programada para el 17 de enero de 2023.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u351) el 17 de febrero de 2023. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

» Notas de la versión 8u351

Java 8 Update 341 (8u341)

Características principales de la versión

Datos de la zona horaria de IANA 2022a.
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Soporte de enlace de canales HTTPS para Java GSS/Kerberos
Ahora están soportados los tokens de enlace de canales TLS para la autenticación Negotiate/Kerberos en HTTPS a través de javax.net.HttpsURLConnection.

Los tokens de enlace de canales son cada vez más necesarios como medida mejorada de seguridad. Lo que hacen es transmitir de un cliente a un servidor la información que tiene el cliente sobre el enlace entre la seguridad de conexión (representada por un certificado de servidor TLS) y las credenciales de autenticación de un nivel más alto (como un nombre de usuario y una contraseña). Entonces, el servidor puede detectar si al cliente lo ha engañado un atacante intermediario (MITM) y cerrar la sesión o conexión.
Consulte JDK-8279842
Nueva función: Activación de TLSv1.3 por defecto en JDK 8u para los roles de cliente
La implantación de TLSv1.3 está disponible en JDK 8u desde la versión 8u261, y se venía activando por defecto para los roles de servidor y desactivando por defecto para los roles de cliente. A partir de esta versión, TLSv1.3 también se activará por defecto para los roles de cliente. Puede obtener más información en la sección Información adicional de Oracle JRE and JDK Cryptographic Roadmap.
Consulte JDK-8245263
Otras notas: Actualización de java.net.InetAddress para detectar literales ambiguos de direcciones IPv4
La clase java.net.InetAddress se ha actualizado para que acepte solo valores literales de direcciones IPv4 que sigan la notación decimal de octetos. Los métodos de la clase InetAddress se han actualizado para que devuelvan una excepción del tipo java.net.UnknownHostException en caso de haber valores literales de direcciones IPv4 no válidos. Para desactivar esta comprobación, la nueva propiedad de sistema "jdk.net.allowAmbiguousIPAddressLiterals" se puede establecer en "true".
Consulte JDK-8277608 (no público)
Otras notas: Extensiones del paquete de JDK truncadas al descargarlo con Firefox 102
En oracle.com y java.com, algunas extensiones del paquete de JDK se truncan al descargarlo con la versión 102 de Firefox. Los paquetes descargados no tienen una extensión de archivo como ".exe", ".rpm" o ".deb". Si no puede actualizar Firefox a la versión ESR 102.0.1, ni a la versión 103 cuando se publique, como solución alternativa puede:
– Agregar manualmente una extensión al nombre del archivo después de descargarlo.
– Utilizar otro navegador.
Consulte JDK-8277093

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda que este JDK (versión 8u341) se utilice después de la próxima actualización de parche crítico programada para el 18 de octubre de 2022.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u341) el 18 de noviembre de 2022. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

» Notas de la versión 8u341

Java 8 Update 333 (8u333)

Características principales de la versión

Datos de la zona horaria de IANA 2021a.
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Cambio: Activar los flujos alternativos de datos de Windows por defecto
La implementación en Windows de java.io.File ha cambiado para que no se realicen estrictas comprobaciones de validez por defecto en las rutas de acceso de archivos. Esto incluye permitir los dos puntos (‘:’) en las rutas de acceso en lugar de permitirlos solo inmediatamente después de una letra de unidad. También se permiten las rutas de acceso que representan flujos alternativos de datos (ADS) de NTFS, como “filename:streamname”. Se restaura el comportamiento por defecto de java.io.File a como era antes de la CPU de abril de 2022, cuando no se realizaban estrictas comprobaciones de validez por defecto en las rutas de acceso de archivos en Windows. Para volver a activar la estricta comprobación de rutas de acceso en java.io.File, la propiedad del sistema jdk.io.File.enableADS debe estar definida en false (mayúsculas/minúsculas ignoradas). Puede ser preferible si, por ejemplo, no se utilizan rutas de acceso de dispositivos especiales de Windows como NUL:.
Consulte JDK-8285445

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda que este JDK (versión 8u333) se utilice después de la próxima actualización de parche crítico programada para el 19 de julio de 2022.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u333) el 19 de agosto de 2022. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

Esta versión se basa en la CPU previa y no contiene ninguna corrección de seguridad adicional. Para acceder a una lista más completa de las correcciones de bugs que incluye esta versión, consulte la página Notas de la versión de JDK 8u333.

» Notas de la versión 8u333

Java 8 Update 331 (8u331)

Características principales de la versión

Datos de la zona horaria de IANA 2021e.
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Nuevo procesamiento XML de límites
Se han agregado tres procesamientos de límites. Son los siguientes:
- jdk.xml.xpathExprGrpLimit
  Descripción: limita el número de grupos que puede contener una expresión XPath.
  Tipo: entero
  Valor: un entero positivo. Un valor menor o igual que 0 indica que no hay ningún límite. Si el valor no es un número entero, ase emite una excepción NumberFormatException. Valor por defecto 10.
- jdk.xml.xpathExprOpLimit
  Descripción: limita el número de operadores que puede contener una expresión XPath.
  Tipo: entero
  Valor: un entero positivo. Un valor menor o igual que 0 indica que no hay ningún límite. Si el valor no es un número entero, ase emite una excepción NumberFormatException. Valor por defecto 100.
- jdk.xml.xpathTotalOpLimit
  Descripción: limita el número total de operadores XPath que puede haber en una hoja de estilos XLS.
  Tipo: entero
  Valor: un entero positivo. Un valor menor o igual que 0 indica que no hay ningún límite. Si el valor no es un número entero, ase emite una excepción NumberFormatException. Valor por defecto 10000.
Procesadores soportados
- jdk.xml.xpathExprGrpLimit y jdk.xml.xpathExprOpLimit están soportados por el procesador XPath.
- Los tres límites están soportados por el procesador XSTL.
Configuración de propiedades
Para el procesador XSLT, se pueden modificar las propiedades mediante TransformerFactory. Por ejemplo,
```
<code>        TransformerFactory factory = TransformerFactory.newInstance();

        factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");
```
Para los procesadores XPath y XSLT, se pueden definir las propiedades mediante la propiedad del sistema y el archivo de configuración jaxp.properties ubicado en el directorio conf de la instalación de Java. Por ejemplo,
```
<code>        System.setProperty("jdk.xml.xpathExprGrpLimit", "20");
```
o en el archivo jaxp.properties,
```
<code>        jdk.xml.xpathExprGrpLimit=20
```
JDK-8270504 (no público)
Otras notas: Mostrar solo certificados con valores de confianza correctos como entradas de certificado de confianza en KeychainStore de macOS
En macOS, solo los certificados con valores de confianza correctos del llavero del usuario se mostrarán como entradas de certificado de confianza en el tipo KeychainStore del almacén de claves. Además, llamar al método KeyStore::setCertificateEntry o al comando keytool -importcert en un almacén de claves KeychainStore emitirá una excepción KeyStoreException. En su lugar, llame al comando "security add-trusted-cert" de macOS para agregar un certificado de confianza al llavero de usuario.
JDK-8278449 (no público)
Otras notas: El análisis de las URL de los proveedores JNDI incorporados LDAP, DNS, RMI y CORBA se ha hecho más preciso. La exactitud del análisis se puede controlar mediante las propiedades del sistema:
El análisis de las URL de los proveedores JNDI incorporados LDAP, DNS, RMI y CORBA se ha hecho más preciso. La exactitud del análisis se puede controlar mediante las propiedades del sistema:
```
<code>  -Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict" (to control "ldap:" URLs)


  -Dcom.sun.jndi.dnsURLParsing="legacy" | "compat" | "strict" (to control "dns:" URLs)

  -Dcom.sun.jndi.rmiURLParsing="legacy" | "compat" | "strict" (to control "rmi:" URLs)

  -Dcom.sun.jndi.corbaURLParsing="legacy" | "compat" | "strict" (to control "iiop:" and "iiopname:" URLs)
```
El valor por defecto es "compat" para todos.
- El modo "legacy" desactiva la nueva validación.
- El modo "compat" limita las incompatibilidades.
- El modo "strict" es más preciso y puede provocar una regresión rechazando las URL que una aplicación puede considerar válidas.
Si se encuentra una URL ilegal, se emite una excepción javax.naming.NamingException (o una subclase de dicha excepción).
JDK-8278972 (no público)

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda que este JDK (versión 8u331) se utilice después de la próxima actualización de parche crítico programada para el 19 de julio de 2022.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u331) el 19 de agosto de 2022. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

» Notas de la versión 8u331

Java 8 Update 321 (8u321)

Características principales de la versión

IANA TZ Data 2021b, 2021c, 2021d, 2021e.
JDK 8u321 contiene datos de zona horaria de IANA, versiones 2021b, 2021c, 2021d y 2021e. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Nuevas propiedades de configuración de SunPKCS11
El proveedor SunPKCS11 agrega nuevos atributos de configuración de proveedor para un mejor control del uso de recursos nativos. El proveedor de SunPKCS11 consume recursos nativos para trabajar con bibliotecas de PKCS11 nativas. Para gestionar y lograr un mejor control de los recursos nativos, se agregan atributos de configuración adicionales para controlar la frecuencia de borrado de las referencias nativas y si se destruye el token subyacente PKCS11 después de cerrar sesión.
Consulte JDK-8240256
Funciones y opciones eliminadas: Eliminación del certificado raíz de GlobalSign de Google
Se ha eliminado el siguiente certificado raíz de Google del almacén de claves cacerts:
+ alias name "globalsignr2ca [jdk]" Distinguished Name: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Consulte JDK-8225083
Otras notas: Actualización de datos de zona horaria a 2021c
La base de datos de zona horaria IANA, en la que se basan las bibliotecas de fecha y hora de JDK, ha hecho un ajuste en algunas reglas de zona horaria desde 2021c. Tenga en cuenta que, desde esta actualización, algunas reglas de zona horaria anteriores al año 1970 han sido modificadas de acuerdo con los cambios introducidos con 2021b. Para obtener más información, consulte el anuncio de 2021b
Consulte JDK-8274407

Actualización de JDK

Oracle recomienda que se actualice el JDK con cada actualización de parche crítico (CPU). Para determinar si una versión es la más reciente, la página de Security Baseline se puede utilizar para determinar cuál es la versión más reciente de cada familia de versiones.

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se anuncian con un año de antelación en la sección Critical Patch Updates, Security Alerts and Bulletins. No se recomienda que este JDK (versión 8u291) se utilice después de la próxima actualización de parche crítico programada para el 20 de julio de 2021.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u291) el 20 de agosto de 2021. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

» Notas de la versión 8u321

Java 8 Update 311 (8u311)

Características principales de la versión

IANA TZ Data 2021a.
Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Marlin Renderer en JDK 8u
A partir de la versión 8u311, el rasterizador de gráficos Marlin y sus artefactos se crearán y se distribuirán como parte de los paquetes de JDK/JRE. No es el motor de representación por defecto, pero hay una opción para activarlo si se configura la siguiente propiedad de sistema:
sun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
Consulte JDK-8143849
Nueva función: Subjuego de filtros de anulación de serialización específicos del contexto
Permite que las aplicaciones configuren filtros de anulación de serialización específicos de contexto y seleccionados dinámicamente a través de una fábrica de filtros de JVM que se llama para seleccionar un filtro para cada flujo de anulación de serialización. El comportamiento es un subjuego estricto de JEP 415: Filtros de anulación de serialización específicos de contexto para permitir que una fábrica de filtros se configure mediante una propiedad configurada en la línea de comandos o en el archivo de propiedades de seguridad.
Consulte Filtros de anulación de serialización específicos de contexto y la guía Filtros de serialización para obtener más información.
JDK-8268680 (no público)
Funciones y opciones eliminadas: Eliminación del certificado raíz de IdenTrust
Se ha eliminado el siguiente certificado raíz de IdenTrust del almacén de claves cacerts
+ alias name "identrustdstx3 [jdk]"
Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.
Consulte JDK-8225082
Otras notas: La versión no reconoce Windows 11 correctamente
Esta versión no identifica Windows 11 correctamente. La propiedad os.name se ha definido paraWindows 10 en Windows 11. En los logs de errores de HotSpot, el sistema operativo se identifica como Windows 10. Sin embargo, el log de errores de HotSpot muestra el número de versión. Windows 11 tiene la versión 22000.194 o superior.
Consulte JDK-8274840
Otras notas: Actualización de la preferencia de conjuntos de cifrados activados por defecto
Se ha ajustado el orden de prioridad establecido por defecto de los conjuntos de cifrado para TLS desde la versión 1.0 hasta la versión 1.3.
Para TLS 1.3, ahora TLS_AES_256_GCM_SHA384 tiene preferencia sobre TLS_AES_128_GCM_SHA256.
Para TLS 1.0 a 1.2, algunos de los conjuntos intermedios han visto reducida su prioridad, como se indica a continuación:
- Se ha reducido más la prioridad de los conjuntos de cifrado que no conservan la confidencialidad directa que la de aquellos que soportan la confidencialidad directa.
- Se ha reducido más la prioridad de los conjuntos de cifrado que utilizan SHA-1.
Consulte JDK-8163326
Otras notas: Modificación del comportamiento de HttpURLConnection cuando no se encuentra un proxy adecuado
El comportamiento de HttpURLConnection al utilizar ProxySelector se ha modificado en esta versión de JDK. La conexión HttpURL se utiliza para recuperar un intento de conexión directa si los proxys configurados no han podido establecer una conexión. En esta versión, se ha cambiado el comportamiento por defecto para que ya no utilice una conexión directa si falla el primer intento de conexión de proxy.
Consulte JDK-8161016

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se publican con un año de antelación en actualizaciones de parches críticos, alertas de seguridad y boletines. No se recomienda que este JDK (versión 8u311) se utilice después de la próxima actualización de parche crítico programada para el 18 de enero de 2022.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores de Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u311) el 18 de febrero de 2022. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la Guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

» Notas de la versión 8u311

Java 8 Update 301 (8u301)

Características principales de la versión

IANA TZ Data 2021a.
JDK 8u301 contiene datos de zona horaria de IANA, versión 2021a. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Personalización de generación de almacén de claves PKCS12
Se han agregado nuevas propiedades de sistema y seguridad para que el usuario pueda personalizar la generación de almacenes de claves de PKCS#12. Incluye algoritmos y parámetros para la protección de claves y certificados y datos de MAC. Puede encontrar una explicación detallada y valores posibles para estas propiedades en la sección "Propiedades de almacén de claves PKCS12" del archivo java.security.
Consulte JDK-8076190
Funciones y opciones eliminadas: Eliminación de certificados raíz con claves de 1024 bits
Se han eliminado los certificados raíz con claves públicas RSA de 1042 bits débiles del almacén de claves cacerts.
Consulte JDK-8243559
Funciones y opciones eliminadas: Eliminación del certificado CA Sonera Class2 de la compañía Telia
Se ha eliminado el siguiente certificado raíz del almacén de confianza cacerts:
+ Telia Company + soneraclass2ca DN: CN=Sonera Class2 CA, O=Sonera, C=FI
Consulte JDK-8225081
Otras notas: Actualización de los algoritmos de cifrado por defecto PKCS12
Se han actualizado los algoritmos de cifrado por defecto utilizados en un almacén de claves PKCS#12. Los nuevos algoritmos basados en AES-256 y SHA-256 son más seguros que los algoritmos anteriores basados en RC2, DESede, y SHA-1. Consulte las propiedades de seguridad que empiezan por keystore.pkcs12 en el archivo java.security para obtener información detallada.
Para garantizar la compatibilidad, se ha definido una nueva propiedad de sistema que revertirá los algoritmos para poder utilizar los algoritmos antiguos y más débiles, llamada keystore.pkcs12.legacy. No se ha definido ningún valor para esta propiedad.
Consulte JDK-8153005

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se anuncian con un año de antelación en la sección Critical Patch Updates, Security Alerts and Bulletins. No se recomienda que este JDK (versión 8u301) se utilice después de la próxima actualización de parche crítico programada para el 19 de octubre de 2021.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u301) el 19 de noviembre de 2021. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la Guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

» Notas de la versión 8u301

Java 8 Update 291 (8u291)

Características principales de la versión

Datos IANA TZ 2020e, 2020f y 2021a.
JDK 8u291 contiene datos de zona horaria IANA versión 2020e, 2020f y 2021a. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Otras notas: sistema y propiedades de seguridad nuevos para controlar la reconstrucción de objetos remotos por parte de implantaciones JNDI RMI y LDAP incorporadas de JDK
jdk.jndi.object.factoriesFilter: este sistema y la propiedad de seguridad permiten que se especifique un filtro de serie que controla el juego de clases de fábrica de objeto permitido para crear una instancia de objetos desde referencias de objetos recuperadas por sistemas de nomenclatura o directorio. La clase de fábrica nombrada por la instancia de referencia coincide con este filtro durante la reconstrucción de referencia remota. La propiedad de filtro soporta sintaxis de filtro basada en patrón con el formato especificado por JEP 290. Esta propiedad se aplica a las implantaciones de proveedor incorporadas de JNDI/RMI y JNDI/LDAP. El valor por defecto permite que cualquier clase de fábrica de objeto especificada en la referencia pueda volver a crear el objeto referenciado.
JDK-8244473 (no público)
Otras notas: la versión de java por defecto no está actualizada para hacer doble clic en ejecución JAR
Si la variable de entorno PATH contiene un registro configurado por instaladores Oracle JDK de versiones más recientes, el instalador Oracle JRE inserta la ruta en el directorio que contiene los comandos de Java (java.exe, javaw.exe, y javaws.exe) en la variable de entorno PATH después de ese registro. Anteriormente, el instalador Oracle JRE ignoraba los cambios realizados en la variable de entorno PATH por parte de los instaladores Oracle JDK de versiones más recientes y actualizaba incorrectamente el valor de variable de entorno PATH. Consulte la CSR que se muestra a continuación para obtener más información técnica: https://bugs.openjdk.java.net/browse/JDK-8259858
Consulte JDK-8259215
Otras notas: Desactivación de TLS 1.0 y 1.1
TLS 1.0 y 1.1 son versiones del protocolo TLS que ya no son seguras y se han sustituido por versiones más seguras y modernas (TLS 1.2 y 1.3).
Estas versiones ahora están desactivadas por defecto. Si se produce algún problema puede, bajo su responsabilidad, volver a activar las versiones al eliminar "TLSv1" y/o "TLSv1.1" de la propiedad de seguridad jdk.tls.disabledAlgorithms en el archivo de configuración java.security.
Consulte JDK-8202343
Otras notas: desactive TLS 1.0 y 1.1 para applets de Java Plugin. Se han desactivado las aplicaciones de Java Web Start
TLS 1.0 y 1.1. Los applets de Java Plugin y las aplicaciones de Java Web Start no utilizan estos protocolos por defecto. Si se produce algún problema, existe una opción para volver a activar los protocolos mediante el panel de control de Java.
JDK-8255892 (no público)

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se anuncian con un año de antelación en la sección Critical Patch Updates, Security Alerts and Bulletins. No se recomienda que este JDK (versión 8u291) se utilice después de la próxima actualización de parche crítico programada para el 20 de julio de 2021.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Correcciones de bugs

» Notas de la versión 8u291

Java 8 Update 281 (8u281)

Características principales de la versión

Datos IANA 2020d
JDK 8u281 contiene datos de zona horaria IANA versión 2020d. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Se ha agregado la opción groupname a la generación de pares de claves keytool
Se ha agregado una nueva opción -groupname a keytool -genkeypair para que el usuario pueda especificar un grupo con nombre al generar un par de claves. Por ejemplo, con keytool -genkeypair -keyalg EC -groupname secp384r1 se generará un par de claves EC con la curva secp384r1. Debido a que puede haber varias curvas con el mismo tamaño, el uso de la opción -groupname tiene prioridad sobre la opción -keysize.
Consulte JDK-8213400
Nueva función: La biblioteca de Apache Santuario se ha actualizado a la versión 2.1.4
La biblioteca de Apache Santuario ha cambiado a la versión 2.1.4. Como consecuencia, se ha introducido una nueva propiedad del sistema, com.sun.org.apache.xml.internal.security.parser.pool-size.
Con esta nueva propiedad del sistema se define el tamaño del pool de la caché de DocumentBuilder interna usada al procesar firmas XML. La función es equivalente a la propiedad del sistema org.apache.xml.security.parser.pool-size que se usa en Apache Santuario y tiene el mismo valor por defecto: 20.
Consulte JDK-8231507
Nueva función: Soporte para la extensión certificate_authorities
"certificate_authorities" es una extensión opcional introducida en TLS 1.3. Se usa para indicar las autoridades de certificación (CA) que soporta un punto final y que debe usar el punto final receptor para guiar la selección del certificado.
Consulte JDK-8206925
Otras notas: Se ha cambiado Properties.loadFromXML para que sea compatible con la especificación
Se ha cambiado la implantación del método java.util.Properties loadFromXML para que sea compatible con su especificación. En concreto, al implantar el analizador XML subyacente, ahora se rechazan los documentos XML no compatibles y se obtiene la excepción InvalidPropertiesFormatException según la especificación del método loadFromXML.
Consulte JDK-8213325
Otras notas: Se ha eliminado el nombre de la zona EE. UU./Nuevo Pacífico como parte de tzdata2020b
Tras la actualización de JDK a tzdata2020b, se han eliminado los archivos pacificnew y systemv, que ya estaban muy obsoletos. Por lo tanto, la zona "EE. UU./Nuevo Pacífico" declarada en el archivo de datos pacificnew ya no se puede utilizar.
Consulte JDK-8254177

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se anuncian con un año de antelación en la sección Critical Patch Updates, Security Alerts and Bulletins. No se recomienda que este JDK (versión 8u281) se utilice después de la próxima actualización de parche crítico programada para el 20 de abril de 2021.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer caducar esta versión de JRE (versión 8u281) el 15 de mayo de 2021. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

» Notas de la versión 8u281

Java 8 Update 271 (8u271)

Características principales de la versión

Datos IANA 2020a
JDK 8u271 contiene datos de zona horaria IANA, versión 2020a. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: curvas débiles con nombre en TLS, CertPath y JAR con firma desactivadas por defecto
Las curvas débiles con nombre se desactivan por defecto al agregarlas a las siguientes propiedades de seguridad disabledAlgorithms: jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms y jdk.jar.disabledAlgorithms. Agregar curvas débiles con nombre individuales a cada propiedad disabledAlgorithms puede ser una tarea tediosa, puesto que son 47 curvas débiles con nombre las que deben desactivarse. Para facilitar esta tarea, se ha implementado una nueva propiedad de seguridad, jdk.disabled.namedCurves, que permite recopilar todas las curvas con nombre comunes a todas las propiedades disabledAlgorithms. Para utilizar la nueva propiedad en las propiedades disabledAlgorithms, utilice la palabra clave include antes del nombre completo de la propiedad. Los usuarios pueden seguir agregando curvas con nombre individuales a las propiedades disabledAlgorithms independientes de esta nueva propiedad. No se pueden incluir otras propiedades en las propiedades disabledAlgorithms.
Consulte JDK-8233228
Nueva función: soporte para Kerberos Cross-Realm Referrals (RFC 6806)
El cliente de Kerberos se ha mejorado con el soporte de adaptación a formato canónico del nombre principal y las referencias cruzadas, tal y como se define en la extensión del protocolo RFC 6806.
Como resultado de la nueva función, el cliente de Kerberos puede aprovechar las configuraciones de entorno más dinámicas y no tiene por qué conocer (de antemano) cómo ejecutar el dominio de un principal de destino (usuario o servicio).
Consulte JDK-8223172
Función eliminada: Java Plugin se ha eliminado de JDK 8u para plataformas Linux, Solaris y MacOS
NPAPI se considera un plugin vulnerable y ha sido desactivado en muchos navegadores. Actualmente, no hay ningún navegador que soporte Java Plugin, basado en NPAPI, en plataformas Linux, Solaris y MacOS.
A partir de 8u271, la parte de Java Plugin responsable de la integración y la interacción con un navegador (en particular, la biblioteca libnpjp2) así como un artefacto asociado no se crearán, y no forma parte de la distribución JRE en plataformas Linux, Solaris y MacOS.
JDK-8240210 (no público)
Otras notas: Propiedad agregada al control de los mecanismos de autenticación de LDAP permitidos para autenticar sobre conexiones claras ("clear")
Una nueva propiedad de entorno, jdk.jndi.ldap.mechsAllowedToSendCredentials, se ha agregado para controlar qué mecanismos de autenticación LDAP pueden enviar credenciales sobre conexiones LDAP clear - una conexión no segura con TLS. Una conexión LDAP encrypted es una conexión abierta al utilizar el esquema ldaps, o una conexión abierta al utilizar el esquema ldap y luego actualizarla a TLS con una operación ampliada STARTTLS.
JDK-8237990 (no público)

Actualización de JDK

Oracle recomienda que se actualice el JDK con cada actualización de parche crítico (CPU). Para determinar si una versión es la más reciente, la siguiente página de Security Baseline se puede utilizar para determinar cuál es la versión más reciente de cada familia de versiones.

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se anuncian con un año de antelación en la sección Critical Patch Updates, Security Alerts and Bulletins. No se recomienda que este JDK (versión 8u271) se utilice después de la próxima actualización de parche crítico programada para el 19 de enero de 2021.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u271) el 20 de febrero de 2021. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

» Notas de la versión 8u271

Java 8 Update 261 (8u261)

Características principales de la versión

Datos IANA 2020a
JDK 8u261 contiene datos de zona horaria IANA versión 2020a. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Cambios de dependencias de la biblioteca (DLL) de Visual Studio de Windows durante el tiempo de ejecución de JDK/JRE
Como parte del mantenimiento continuo, la cadena de herramientas de Microsoft Visual Studio 2017 se utilizará para generar JDK 7 y JDK 8 para Windows. JDK 8u261, incluido en la CPU de julio de 2020, se generó con Visual Studio 2017. Con la versión de la CPU de octubre de 2020, JDK 7u281 se moverá a Visual Studio 2017.
JDK-8246783 (no público)
Nueva función: Seguridad de Capa de Transporte (TLS) 1.3 de JEP 332
JDK 8u261 incluye una implantación de la especificación de Seguridad de Capa de Transporte (TLS) 1.3 (RFC 8446). Para obtener más información, incluida una lista de las funciones soportadas, consulte la documentación de la guía de referencia de la extensión de sockets seguros de Java (JSSE) y JEP 332.
Consulte JDK-814252
Nueva función: Nuevas propiedades del sistema para configurar los esquemas de firma de TLS
Se han agregado dos nuevas propiedades del sistema para personalizar los esquemas de firma de TLS en JDK.
Se ha agregado jdk.tls.client.SignatureSchemes para el cliente de TLS y jdk.tls.server.SignatureSchemes para el servidor.
Consulte JDK-8242141
Nueva función: Negociación de parámetros Diffie-Hellman Ephemeral de campo finito para TLS
La implantación JDK SunJSSE es ahora compatible con los mecanismos FFDHE de TLS definidos en RFC 7919. Si un servidor no puede procesar la extensión TLS supported_groups o los grupos con nombre de la extensión, las aplicaciones pueden personalizar los nombres de grupos soportados con jdk.tls.namedGroups o bien desactivar los mecanismos FFDHE definiendo la propiedad del sistema jsse.enableFFDHE en false.
Consulte JDK-8140436

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se anuncian con un año de antelación en la sección Critical Patch Updates, Security Alerts and Bulletins. No se recomienda que este JDK (versión 8u261) se utilice después de la próxima actualización de parche crítico programada para el 13 de octubre de 2020.

Los clientes con suscripción a Java SE que gestionen actualizaciones/instalaciones de JRE para un gran número de escritorios deben considerar utilizar Java Advanced Management Console (AMC).

Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer caducar esta versión de JRE (versión 8u261) el 13 de noviembre de 2020. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

» Notas de la versión 8u261

Java 8 Update 251 (8u251)

Características principales de la versión

Datos IANA 2019c
JDK 8u251 contiene datos de zona horaria IANA versión 2019c. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Soporte agregado para algoritmos PKCS#1 v2.2 incluyendo firma RSASSA-PSS
Los proveedores SunRsaSign y SunJCE se han mejorado con soporte para más algoritmos definidos en PKCS#1 v2.2, como la firma RSASSA-PSS y OAEP mediante algoritmos de síntesis FIPS 180-4. Se han agregado nuevos constructores y métodos a las clases JCA/JCE relevantes bajo los paquetes java.security.spec y javax.crypto.spec para soportar los parámetros adicionales RSASSA-PSS.
Consulte JDK-8146293
Otras notas: WebEngine limita las llamadas del método de JavaScript para algunas clases
Los programas JavaScript que se ejecutan en el contexto de una página web cargada por WebEngine pueden comunicarse con objetos Java que se pasan de la aplicación al programa JavaScript. Los programas JavaScript que hacen referencia a objetos java.lang.Class ahora se limitan a los siguientes métodos:
getCanonicalName getEnumConstants getFields getMethods getName getPackageName getSimpleName getSuperclass getTypeName getTypeParameters isAssignableFrom isArray isEnum isInstance isInterface isLocalClass isMemberClass isPrimitive isSynthetic toGenericString toString

No se puede llamar a ningún método en las siguientes clases:
java.lang.ClassLoader java.lang.Module java.lang.Runtime java.lang.System java.lang.invoke.* java.lang.module.* java.lang.reflect.* java.security.* sun.misc.*

JDK-8236798 (no público)
Otras notas: Una nueva propiedad de sistema de actualizaciones JDK 8 específicas de Oracle 8 volverá al formato de codificación antiguo Base64
Oracle JDK 8u231 ha actualizado las bibliotecas de Apache Santuario a v2.1.3. Esta actualización ha introducido una incidencia por la que la firma XML que utiliza codificación Base64 provocaba la adición de &#xd o &#13 a la salida codificada. Este cambio de comportamiento se ha hecho en el codebase de Apache Santuario para ajustarse a RFC 2045. El equipo de Santuario ha adoptado una posición de mantener sus bibliotecas compatibles con RFC 2045.
Consulte JDK-8236645

Actualización de JDK

Las actualizaciones de parches críticos, que contienen correcciones de vulnerabilidades de seguridad, se anuncian con un año de antelación en la sección Critical Patch Updates, Security Alerts and Bulletins. No se recomienda que este JDK (versión 8u251) se utilice después de la próxima actualización de parche crítico programada para el 14 de julio de 2020.

Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer caducar esta versión de JRE (versión 8u211) el 14 de agosto de 2020. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión. Para más información, consulte 23.1.2 Fecha de caducidad de JRE en la guía de despliegue de Java Platform, Standard Edition.

Correcciones de bugs

» Notas de la versión 8u251

Java 8 Update 241 (8u241)

Características principales de la versión

Datos IANA 2019c
JDK 8u241 contiene datos de zona horaria IANA versión 2019c. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Permitir restricción de mecanismos SASL
Se ha agregado una propiedad de seguridad denominada jdk.sasl.disabledMechanisms que se puede usar para desactivar los mecanismos SASL. Si se especifica en el argumento mechanisms de Sasl.createSaslClient o en el argumento mechanism de Sasl.createSaslServer, se ignorará cualquier mecanismo desactivado. El valor por defecto para esta propiedad de seguridad está vacío, lo que significa que no habrá ningún mecanismo desactivado per se.
Consulte JDK-8200400
Nueva función: Proveedor SunPKCS11 actualizado, con soporte para PKCS#11 v2.40
El proveedor SunPKCS11 se ha actualizado con soporte para PKCS#11 v2.40. Esta versión agrega soporte para más algoritmos como el cifrado AES/GCM/NoPadding, las firmas DSA que utilizan la familia SHA-2 de resúmenes de mensajes y las firmas RSASSA-PSS si los mecanismos PKCS11 correspondientes están soportados por la biblioteca de PKCS11 subyacente.
Consulte JDK-8080462
Otras notas: Nuevas comprobaciones en certificados de anclaje de confianza
Se han agregado nuevas comprobaciones para garantizar que los anclajes de confianza son certificados de CA y contienen las extensiones adecuadas. Los anclajes de confianza se utilizan para validar las cadenas de certificados utilizadas en TLS y en el código firmado. Los certificados de anclaje de confianza deben incluir una extensión de restricciones básicas y tener el campo CA definido en true. Además, si incluyen una extensión de uso de claves, deberán tener definido el bit keyCertSign.
JDK-8230318 (no público)
Otras notas: Coincidencia exacta necesaria para certificado de servidor TLS de confianza
Un certificado de servidor TLS debe coincidir exactamente con un certificado de confianza en el cliente para que se considere de confianza al establecer una conexión TLS.
JDK-8227758 (no público)
Otras notas: Agregado el certificado LuxTrust Global Root 2
Se ha agregado el certificado raíz LuxTrust al almacén de confianza cacerts.
Consulte JDK-8232019
Otras notas: Agregados 4 certificados de CA raíz de Amazon
Se han agregado certificados raíz de Amazon al almacén de confianza cacerts.
Consulte JDK-8233223
Correcciones de bugs: Soporte de fuentes OpenType CFF
Hasta ahora, Oracle JDK 8 no incluía fuentes OpenType CFF (fuentes .otf) entre sus fuentes lógicas estándar (como "Dialog" y "SansSerif"). Como consecuencia, al representar el texto faltaban glifos. En el caso extremo de que en el sistema solo hubiera instaladas fuentes CFF, se podía devolver una excepción Java.
Algunas distribuciones Linux se veían afectadas por este problema porque utilizan fuentes CFF para la localización a determinados idiomas, algo muy común para las lenguas CJK (chino, japonés y coreano).
Ahora Oracle JDK 8 usa estas fuentes CFF, y se ha resuelto este problema.
Consulte JDK-8209672
Correcciones de bugs: Mejora en el manejo de filtros de serie
La propiedad de sistema jdk.serialFilter solo se puede definir en la línea de comandos. Si no se ha definido el filtro en la línea de comandos, se puede definir con java.io.ObjectInputFilter.Config.setSerialFilter. Si define jdk.serialFilter con java.lang.System.setProperty, no tendrá ningún efecto.
JDK-8231422 (no público)

Fecha de caducidad de Java

8u241 caduca el 14 de abril de 2020. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer caducar esta versión de JRE (versión 8u241) el 14 de mayo de 2020. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u241

Java 8 Update 231 (8u231)

Características principales de la versión

Datos IANA 2019b
JDK 8u231 contiene datos de zona horaria IANA versión 2019b. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Nueva propiedad del sistema jdk.jceks.iterationCount
Se ha incorporado una nueva propiedad de sistema para controlar el valor de recuento de iteraciones utilizado para el almacén de claves jceks. El valor por defecto sigue siendo 200000, pero se pueden especificar valores de entre 10000 y 5000000. El nombre de la nueva propiedad del sistema es jdk.jceks.iterationCount y el valor que se indique debe ser un entero dentro del rango aceptado. Se usará el valor por defecto si se encuentra un error de análisis.
JDK-8223269 (no público)
Nueva función: Nuevos eventos de seguridad de Java Flight Recorder (JFR)
Se han agregado cuatro nuevos eventos de JFR al área de biblioteca de seguridad. Estos eventos están desactivados por defecto y se pueden activar mediante los archivos de configuración de JFR o mediante las opciones de JFR estándar.
Consulte JDK-8148188
Funciones y opciones eliminadas: Eliminación del rasterizador T2K y el motor de diseño ICU en JavaFX
Se han eliminado de JavaFX el rasterizador T2K y el motor de diseño ICU.
Consulte JDK-8187147
Otras notas: [client-libs y JavaFX] GTK3 ahora es la biblioteca por defecto en Linux/Unix
En las nuevas versiones de Linux, Solaris y otros tipos de entornos de escritorio Unix se utiliza GTK3, pero GTK2 sigue estando soportado.
Hasta ahora, JDK cargaba por defecto las antiguas bibliotecas GTK2. Sin embargo, en esta versión, cargará por defecto las bibliotecas GTK3. Normalmente, la carga se dispara al usar la apariencia GTK de Swing.
Se puede restaurar el comportamiento antiguo mediante la siguiente propiedad de sistema: -Djdk.gtk.version=2.2
Consulte JDK-8222496
Otras notas: Eliminación de las curvas EC de NIST obsoletas en los algoritmos TLS por defecto
Con este cambio se eliminan las curvas EC de NIST obsoletas de los grupos con nombre por defecto utilizados en la negociación de TLS. Las curvas eliminadas son sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 y secp256k1.
Para volver a activar estas curvas, utilice la propiedad del sistema jdk.tls.namedGroups. La propiedad contiene una lista de grupos con nombre activados en orden de preferencia, separados por comas y entre comillas. Por ejemplo:
java -Djdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1" ...
JDK-8228825 (no público)

Fecha de caducidad de Java

La fecha de caducidad de 8u231 es el 14 de enero de 2020. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer que caduque esta versión de JRE (versión 8u231) el 14 de febrero de 2020. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u231

Java 8 Update 221 (8u221)

Características principales de la versión

Datos IANA 2018i
JDK 8u221 contiene datos de zona horaria IANA versión 2018i. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: detección de hotspot del sistema operativo de Windows que identifica correctamente Windows Server 2019.
Antes de esta corrección, a Windows Server 2019 se lo reconocía como "Windows Server 2016", lo que producía valores incorrectos en la propiedad del sistema os.name y en el archivo hs_err_pid.
Consulte JDK-8211106
Funciones y opciones eliminadas: Eliminación de dos certificados de CA raíz de DocuSign.
Dos certificados de CA raíz de DocuSign han caducado y se han eliminado del almacén de claves cacerts:
- alias name "certplusclass2primaryca [jdk]"
  Nombre distintivo: CN=Class 2 Primary CA, O=Certplus, C=FR
- alias name "certplusclass3pprimaryca [jdk]"
  Nombre distintivo: CN=Class 3P Primary CA, O=Certplus, C=FR
Consulte JDK-8223499
Funciones y opciones eliminadas: Eliminación de dos certificados de CA raíz de Comodo
Dos certificados de CA raíz de Comodo han caducado y se han eliminado del almacén de claves cacerts:
- alias name "utnuserfirstclientauthemailca [jdk]"
  Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
- alias name "utnuserfirsthardwareca [jdk]"
  Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Consulte JDK-8222136
Funciones y opciones eliminadas: Eliminación del certificado de CA 2 raíz de T-Systems Deutsche Telekom.
El certificado de CA 2 raíz de T-Systems Deutsche Telekom ha caducado y se ha eliminado del almacén de claves cacerts:
- alias name "deutschetelekomrootca2 [jdk]"
  Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
Consulte JDK-8222137
Otras notas: Solución alternativa para la instalación de Java Access Bridge.
Existe un riesgo de interrupción de la funcionalidad de Java Access Bridge al instalar Java en un sistema Windows que tiene una versión de Java instalada previamente y una instancia de JAWS en ejecución. Tras reiniciar, se puede dejar al sistema sin el archivo WindowsAccessBridge-64.dll tanto en el directorio del sistema (C:\Windows\System32) para productos de Java de 64 bits como en el directorio del sistema que utiliza WOW64 (C:\Windows\SysWoW64) para productos de Java de 32 bits.
Para evitar la interrupción de la funcionalidad de Java Access Bridge, pruebe una de las siguientes soluciones alternativas:
- Detenga JAWS antes de ejecutar el instalador de Java.
- Desinstale los JRE existentes antes de instalar la nueva versión de Java.
- Desinstale los JRE existentes después de instalar la nueva versión de Java y reiniciar la máquina.
El objetivo de las soluciones alternativas es evitar la desinstalación de JRE existentes del instalador de Java cuando JAWS se está ejecutando.
JDK-8223293 (no público)

Fecha de caducidad de Java

La fecha de caducidad de 8u221 es el 15 de octubre de 2019. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer caducar esta versión de JRE (versión 8u221) el 15 de noviembre de 2019. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u221

Java 8 Update 211 (8u211)

Características principales de la versión

Datos de IANA 2018g
JDK 8u211 contiene datos de zona horaria de IANA versión 2018g. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Soporte del carácter cuadrado del kanji de la nueva era japonesa
El Unicode Consortium ha reservado el punto de código U+32FF para representar el carácter cuadrado japonés de la nueva era que comienza en mayo de 2019. Los métodos correspondientes de la clase Character devuelven las mismas propiedades que los caracteres de era japonesa existentes (por ejemplo, U+337E para "Meiji"). Para obtener más información sobre el punto de código, consulte http://blog.unicode.org/2018/09/new-japanese-era.html.
Consulte JDK-8211398
Cambio: Adición del certificado raíz GlobalSign R6
Se ha agregado el siguiente certificado raíz al almacén de confianza cacerts de OpenJDK:
- GlobalSign
  - globalsignrootcar6
    DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R6
JDK-8216577 (no público)
Cambio: Eliminación de certificados de servidor TLS fijados por la raíz de Symantec
El JDK dejará de confiar en los certificados de servidor TLS emitidos por Symantec, de conformidad con planes similares anunciados recientemente por Google, Mozilla, Apple y Microsoft. En la lista de certificados afectados están incluidos los certificados denominados GeoTrust, Thawte y VeriSign, de cuya gestión se encargaba Symantec.
Los certificados de servidor TLS emitidos el 16 de abril de 2019 o antes de esa fecha seguirán considerándose de confianza hasta que caduquen. Los certificados emitidos tras dicha fecha se rechazarán. Consulte la página de soporte de DigiCert para obtener información sobre cómo reemplazar los certificados de Symantec por uno de DigiCert (DigiCert tomó posesión de la validación y emisión de todos los certificados SSL/TLS de Symantec Website Security el 1 de diciembre de 2017).
Hay una excepción a esta política: los certificados de servidor TLS emitidos a través de dos autoridades de certificación subordinadas que gestiona Apple, y que se identifican a continuación, seguirán considerándose de confianza siempre que se hayan emitido el 31 de diciembre de 2019 o antes de esa fecha.
Consulte JDK-8207258
Cambio: Nuevo nombre de era japonesa
El nombre de marcador de posición "NewEra" correspondiente a la era japonesa que comenzó el 1 de mayo de 2019 se ha reemplazado por el nombre anunciado por el Gobierno nipón: "Reiwa". Las aplicaciones que usen el nombre del marcador de posición para obtener el singleton de nueva era (JapaneseEra.valueOf("NewEra")) dejarán de funcionar.
Consulte JDK-8205432
Cambio: Soporte de la nueva era japonesa en java.time.chrono.JapaneseEra
La clase JapaneseEra y sus métodos of(int), valueOf(String) y values() se han clarificado para ofrecer soporte a nuevas incorporaciones de eras japonesas en el futuro. Por ejemplo, se han aclarado los métodos de definición de instancias singleton y los valores enteros de era correspondientes, entre otros elementos .
Consulte JDK-8212941

Fecha de caducidad de Java

La fecha de caducidad de 8u211 es el 16 de julio de 2019. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer caducar esta versión de JRE (versión 8u211) el 16 de agosto de 2019. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Esta versión contiene correcciones para las vulnerabilidades de seguridad descritas en Asesor de actualización de parche crítico de Oracle Java SE. Para acceder a una lista más completa de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u211.

» Notas de la versión 8u211

Java 8 Update 201 (8u201)

Características principales de la versión

Datos IANA 2018e
JDK 8u201 contiene datos de zona horaria IANA versión 2018e. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Cambio: Desactivados los conjuntos de cifrado TLS anon y NULL
Los conjuntos de cifrado TLS anon (anónimo) y NULL se han agregado a la propiedad de seguridad jdk.tls.disabledAlgorithms y ahora se desactivan por defecto.
Consulte JDK-8211883
Cambio: jarsigner muestra cuándo caduca un registro de hora
La herramienta jarsigner ahora muestra más información sobre el ciclo de vida de un JAR con registros de hora. Se muestran nuevos mensajes de advertencia y error cuando ha caducado un registro de hora o si caduca dentro de un año.
Consulte JDK-8191438

Fecha de caducidad de Java

8u201 caduca el 16 de abril de 2019. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de hacer caducar esta versión de JRE (versión 8u201) el 16 de mayo de 2019. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u201

Java 8 Update 191 (8u191)

Características principales de la versión

Datos IANA 2018e
JDK 8u191 contiene datos de zona horaria IANA versión 2018e. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Cambio: Se ha cambiado la ubicación del sistema de archivos central del archivo usagetracker.properties
La ubicación del sistema de archivos en Windows correspondiente al archivo usagetracker.properties se ha movido de %ProgramData%\Oracle\Java\ a %ProgramFiles%\Java\conf.
La ruta del archivo no ha cambiado en Linux, Solaris ni macOS. JDK-8204901 (no público)
Cambio: Desactivados todos los conjuntos de cifrado TLS de DES
Los conjuntos de cifrado TLS basados en DES se consideran obsoletos, por lo que no deben seguir usándose. Los conjuntos de cifrado TLS basados en DES se han desactivado por defecto en la implantación de SunJSSE agregando el identificador "DES" a la propiedad de seguridad jdk.tls.disabledAlgorithms. Estos conjuntos de cifrado pueden reactivarse eliminando "DES" de la propiedad de seguridad jdk.tls.disabledAlgorithms en el archivo java.security o llamando de forma dinámica al método Security.setProperty(). En ambos casos, después de reactivar el DES se deben añadir conjuntos de cifrado basados en DES para la lista de conjunto de cifrado activada, utilizando los métodos SSLSocket.setEnabledCipherSuites() o SSLEngine.setEnabledCipherSuites().
Tenga en cuenta que, antes de realizar este cambio, los conjuntos DES40_CBC (pero no todos los de DES) se desactivaron con la propiedad de seguridad jdk.tls.disabledAlgorithms.
Consulte JDK-8208350
Cambio: Eliminación de varios CA de raíz de Symantec
Los siguientes certificados de raíz de Symantec ya no están en uso y se han eliminado:
- Symantec
  - equifaxsecureca
    DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
  - equifaxsecureglobalebusinessca1
    DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
  - equifaxsecureebusinessca1
    DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
  - verisignclass1g3ca
    DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass2g3ca
    DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass1g2ca
    DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
  - verisignclass1ca
    DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Consulte JDK-8191031
Cambio: Eliminación de la CA de firma de código Baltimore CyberTrust
El siguiente certificado de raíz de firma de código de Baltimore CyberTrust ya no está en uso y se ha eliminado:
- baltimorecodesigningca
  DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
Consulte JDK-8189949
Corrección de bug: Fallo de comunicación LDAPS
El código de aplicación que utilice LDAPS con un timeout de conexión a socket <= 0 (el valor por defecto) y que se ejecute en la actualización de parche crítico de julio de 2018 ( 8u181, 7u191 y 6u201 ) puede encontrar una excepción al establecer la conexión.
En los marcos superiores de los rastreos de pila de las aplicaciones que encuentran este problema puede aparecer algo como esto:
javax.naming.ServiceUnavailableException: ; socket closed
at com.sun.jndi.ldap.Connection.readReply(Unknown Source)
at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) ...
El problema se ha resuelto y la corrección está disponible en las siguientes versiones:
- 8u181
- 7u191
Consulte JDK-8211107

Fecha de caducidad de Java

La fecha de caducidad de 8u191 es el 15 de enero de 2019. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u191) el 15 de febrero de 2019. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u191

Java 8 Update 181 (8u181)

Características principales de la versión

Datos IANA 2018e
JDK 8u181 contiene datos de zona horaria IANA versión 2018e. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Función eliminada: Eliminación de Java DB
Java DB, también conocido como Apache Derby, se ha eliminado en esta versión.
Recomendamos obtener la versión más reciente de Apache Derby directamente del proyecto Apache:
https://db.apache.org/derby
JDK-8197871 (no público)
Cambio: Mejora de la compatibilidad con LDAP
La identificación de puntos finales se ha activado en las conexiones LDAPS.
Para mejorar la solidez de las conexiones LDAPS (LDAP seguro en TLS), los algoritmos de identificación de puntos finales se han activado por defecto.
Tenga en cuenta que puede haber situaciones en las que algunas aplicaciones que antes podían conectarse a un servidor de LDAP ya no puedan hacerlo. Si lo consideran necesario, dichas aplicaciones podrían desactivar la identificación de puntos finales usando una nueva propiedad de sistema: com.sun.jndi.ldap.object.disableEndpointIdentification.
Defina esta propiedad de sistema (o establézcala en true) para desactivar los algoritmos de identificación de puntos finales.
JDK-8200666 (no público)
Cambio: Mejor recorrido de pila
Se han agregado nuevas comprobaciones de acceso durante la fase de creación de objetos en la deserialización. Este cambio no debería influir en los usos comunes de la deserialización. Sin embargo, puede que afecte a los marcos de reflejo que hacen uso de las API internas de JDK. Si es necesario, las comprobaciones nuevas se pueden desactivar definiendo el valor de la propiedad de sistema jdk.disableSerialConstructorChecks en "true". Para ello, se debe agregar el argumento -Djdk.disableSerialConstructorChecks=true a la línea de comandos Java.
JDK-8197925 (no público)
Corrección de bug: Bloqueo de JVM durante G1 GC
Una clase que se haya considerado inaccesible por parte del marcado de G1 se puede buscar en ClassLoaderData/SystemDictionary, y sus campos _java_mirror o _class_loader se pueden almacenar en una raíz o en cualquier otro objeto accesible para volver a activarla. Siempre que se recupera una clase de esta manera, se debe informar a la parte SATB de G1. De lo contrario, la fase de marcado simultánea descargará dicha clase por error.
Consulte JDK-8187577
Corrección de bug: Mayor estabilidad con bibliotecas NUMA anteriores (-XX+UseNuma)
Una corrección incluida en JDK 8 Update 152 generó una regresión que puede causar el bloqueo de JVM HotSpot al iniciar cuando el indicador UseNUMA se usa en sistemas Linux con versiones de libnuma previas a la 2.0.9. Este error se ha resuelto.
Consulte JDK-8198794

Fecha de caducidad de Java

La fecha de caducidad de 8u181 es el 16 de octubre de 2018. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u181) el 16 de noviembre de 2018. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u181

Java 8 Update 171 (8u171)

Características principales de la versión

Datos IANA 2018c
JDK 8u171 contiene datos de zona horaria IANA versión 2018c. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Mejora en los mecanismos del almacén de claves
Se ha introducido una nueva propiedad de seguridad denominada jceks.key.serialFilter. Si se configura este filtro, el almacén de claves de JCEKS lo utiliza durante la anulación de la serialización del objeto de clave cifrado almacenado en una entrada SecretKeyEntry. Si no está configurado o si el resultado del filtro es UNDECIDED (por ejemplo, no coincide ninguno de los patrones), se consultará el filtro configurado por jdk.serialFilter.
Si también se proporciona la propiedad del sistema jceks.key.serialFilter, esta sustituye al valor de propiedad de seguridad que se defina en este apartado.
El patrón de filtro utiliza el mismo formato que jdk.serialFilter. El patrón por defecto permite java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type y javax.crypto.spec.SecretKeySpec, pero rechaza el resto.
Los clientes que almacenan un elemento SecretKey que no se serialice con ninguno de los tipos anteriores deberán modificar el filtro para poder extraer la clave.
JDK-8189997 (no público)
Nueva función: Propiedad del sistema para desactivar el seguimiento de uso más reciente de JRE
Se ha introducido una nueva propiedad de sistema, jdk.disableLastUsageTracking, para desactivar el seguimiento de uso más reciente de JRE para una máquina virtual en ejecución. Esta propiedad se puede definir en la línea de comandos. Para ello, utilice -Djdk.disableLastUsageTracking=true o -Djdk.disableLastUsageTracking. Una vez definida esta propiedad del sistema, el seguimiento de uso más reciente de JRE estará desactivado independientemente del valor de la propiedad com.oracle.usagetracker.track.last.usage que se haya definido en usagetracker.properties.
JDK-8192039 (no público)
Nota: Uso de CipherOutputStream
Se ha clarificado la especificación de javax.crypto.CipherOutputStream para indicar que esta clase detecta la excepción BadPaddingException y otras excepciones devueltas tras producirse fallos en las comprobaciones de integridad durante el descifrado. Estas excepciones no se vuelven a emitir, así que el cliente no recibe información sobre los fallos en las comprobaciones de integridad. Debido a este comportamiento, puede que esta clase no sea la adecuada para utilizarla con el descifrado en un modo autenticado de funcionamiento (por ejemplo, GCM) si la aplicación requiere que se notifiquen puntualmente los fallos de autenticación. Estas aplicaciones puede utilizar la API de cifrado directamente como alternativa a esta clase.
JDK-8182362 (no público)
Cambio: Certificado raíz de TeliaSonera adicional
Se ha agregado "TeliaSonera Root CA v1" al almacén de claves cacerts.
JDK-8190851 (no público)
Cambio: Firmas XML con claves EC inferiores a 224 bits desactivadas
Para mejorar la fortaleza de las conexiones SSL/TLS, se han desactivado los conjuntos de cifrado 3DES en las conexiones SSL/TLS de JDK mediante la propiedad de seguridad jdk.tls.disabledAlgorithms.
JDK-8175075 (no público)
Corrección de bug: Conexiones RMI de canal HTTP de servidor desactivadas
Las conexiones RMI de canal HTTP de servidor están desactivadas por defecto en esta versión. Este comportamiento se puede revertir. Para ello, defina la propiedad en ejecución sun.rmi.server.disableIncomingHttp en false. Tenga en cuenta que no se debe confundir con la propiedad sun.rmi.server.disableHttp, que desactiva el canal HTTP en el cliente y está definida en false por defecto.
JDK-8193833 (no público)

Fecha de caducidad de Java

8u171 caduca el 17 de julio de 2018. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u171) el 17 de agosto de 2018. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u171

Java 8 Update 161 (8u161)

Características principales de la versión

Datos IANA 2017c
JDK 8u161 contiene datos de zona horaria IANA versión 2017c. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Nueva función: Compatibilidad con parámetros DHE de hasta 8192 bits y DSA de hasta 3072 bits
Mejora en los proveedores de seguridad JDK, que ahora soportan la generación de parámetros Diffie-Hellman y DSA de 3072 bits, así como parámetros Diffie-Hellman precalculados de 8192 bits y parámetros DSA precalculados de 3072 bits.
Consulte JDK-8072452
Nueva función: Negociación de parámetros Diffie-Hellman Ephemeral de campo finito para TLS
La implantación JDK SunJSSE es ahora compatible con los mecanismos FFDHE de TLS definidos en RFC 7919. Si un servidor no puede procesar la extensión TLS supported_groups o los grupos con nombre de la extensión, las aplicaciones pueden personalizar los nombres de grupos soportados con jdk.tls.namedGroups o bien desactivar los mecanismos FFDHE definiendo la propiedad de sistema jsse.enableFFDHEExtension en false.
Consulte JDK-8140436
Nueva función: Incorporación de comprobaciones de tipo stub IDL adicionales al método org.omg.CORBA.ORBstring_to_object
Las aplicaciones que llamen explícita o implícitamente a org.omg.CORBA.ORB.string_to_object y quieran garantizar la integridad del tipo stub IDL del flujo de llamada ORB::string_to_object deberán especificar la comprobación de tipo stub IDL adicional. Esta opción es adicional y no está activada por defecto.
Para aprovechar esta comprobación de tipos adicional, la lista de nombres de clase de interfaz IDL válidos de clases stub IDL se puede configurar siguiendo alguno de los siguientes métodos:
- Especificando la propiedad de seguridad com.sun.CORBA.ORBIorTypeCheckRegistryFilter del archivo conf/security/java.security en Java SE 9 o en jre/lib/security/java.security en Java SE 8 y versiones anteriores.
- Especificando la propiedad del sistema com.sun.CORBA.ORBIorTypeCheckRegistryFilter con la lista de clases. Si la propiedad del sistema está definida, su valor sustituye a la propiedad correspondiente definida en la configuración de java.security.
Si la propiedad com.sun.CORBA.ORBIorTypeCheckRegistryFilter no está definida, la comprobación de tipos solo se realiza en un juego de nombres de clase de los tipos de interfaz IDL correspondientes a las clases stub IDL integradas.
JDK-8160104 (no público)
Cambio: Validación de clave pública de RSA
En 8u161, la implantación de RSA en el proveedor SunRsaSign supondrá el rechazo de cualquier clave pública de RSA con un exponente que no esté en el rango definido por la versión 2.2 de PKCS#1. Este cambio afectará a las conexiones de JSSE y a las aplicaciones de JCE.
JDK-8174756 (no público)
Cambio: Restricción de claves Diffie-Hellman de menos de 1024 bits
Las claves Diffie-Hellman de menos de 1024 bits se consideran demasiado débiles para utilizarlas en la práctica y se deben restringir por defecto en las conexiones SSL/TLS/DTLS. De ahí que las claves Diffie-Hellman de menos de 1024 bits se hayan desactivado por defecto agregando el parámetro "DH keySize < 1024" a la propiedad de seguridad "jdk.tls.disabledAlgorithms" del archivo java.security. Aunque no se recomienda, los administradores pueden actualizar la propiedad de seguridad ("jdk.tls.disabledAlgorithms") para permitir el uso de claves de menor tamaño (por ejemplo, definiendo el parámetro "DH keySize < 768").
JDK-8148108 (no público)
Cambio: Actualización del tamaño de la clave por defecto del proveedor
Este cambio supone la actualización de los proveedores JDK para que utilicen 2048 bits como tamaño por defecto de DSA en lugar de 1024 bits, en el caso de que las aplicaciones no hayan inicializado explícitamente los objetos java.security.KeyPairGenerator y java.security.AlgorithmParameterGenerator con un tamaño de clave.
Si surgen problemas de compatibilidad, las aplicaciones existentes pueden definir la propiedad del sistema jdk.security.defaultKeySize introducida en JDK-8181048 con el algoritmo y el tamaño de clave por defecto que necesiten.
JDK-8178466 (no público)

Fecha de caducidad de Java

8u161 caduca el 17 de abril de 2018. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u161) el 17 de mayo de 2018. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u161

Java 8 Update 151 (8u151)

Características principales de la versión

Datos IANA 2017b
JDK 8u151 contiene datos de zona horaria IANA versión 2017b. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Cambios de certificado: Eliminación de certificado revocado de Swisscom "swisscomrootevca2"
Swisscom ha revocado un certificado raíz y se ha eliminado: Swisscom Root EV CA 2 alias: "swisscomrootevca2 [jdk]" DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
JDK-8186330 (no público)
Nuevas funciones Nueva propiedad de seguridad para controlar la política de cifrado
Esta versión incluye una nueva función por la que los archivos de la política de jurisdicción de JCE utilizados por JDK se pueden controlar mediante una nueva propiedad de seguridad. En versiones anteriores, los archivos de la jurisdicción JCE tenían que descargarse e instalarse por separado para permitir que JDK utilizase el cifrado ilimitado. Los pasos de descarga e instalación ya no son necesarios. Para activar el cifrado ilimitado, se puede utilizar la nueva propiedad de seguridad crypto.policy. Si la nueva propiedad de seguridad (crypto.policy) se define en el archivo java.security, o se ha definido dinámicamente mediante la llamada Security.setProperty() antes de que se haya inicializado el marco JCE, ese valor se mantendrá. Por defecto, la propiedad estará sin definir. Si la propiedad no está definida y los archivos de jurisdicción JCE antiguos no existen en el directorio lib/security antiguo, el nivel de cifrado por defecto seguirá siendo "limitado". Para configurar el JDK para que utilice el cifrado ilimitado, defina el valor crypto.policy en un valor de 'ilimitado'. Consulte las notas del archivo java.security incluido con esta versión para obtener más información.
Nota: En Solaris, se recomienda que elimine los paquetes SVR4 antiguos antes de instalar las nuevas actualizaciones de JDK. Si un cambio de versión basado en SVR4 (sin desinstalar los paquetes antiguos) se lleva a cabo en una versión de JDK anterior a las versiones 6u131, 7u121, 8u111, deberá definir la nueva propiedad de seguridad crypto.policy en el archivo java.security.

Debido a que los antiguos archivos de jurisdicción de JCE se mantienen en <java-home>/lib/security, puede que no cumplan los estándares de firma JAR de seguridad más recientes, refrescados en las versiones 6u131, 7u121, 8u111 y actualizaciones posteriores. Si se utilizan los archivos antiguos, puede aparecer una excepción similar a la siguiente:

Causado por: java.lang.SecurityException: Los archivos de la política de jurisdicción no están firmados por firmantes de confianza en javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) en javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)
Consulte JDK-8157561
Cambios: Refactorizar proveedores existentes para hacer referencia a las mismas constantes para los valores por defecto de la longitud de la clave
Se han realizado dos cambios importantes para resolver este problema:
1. Se ha introducido una nueva propiedad del sistema que permite a los usuarios configurar el tamaño de clave por defecto utilizado por las implementaciones del proveedor de JDK de KeyPairGenerator y AlgorithmParameterGenerator. Esta propiedad se denomina "jdk.security.defaultKeySize" y el valor de esta propiedad es una lista de entradas separadas por comas. Cada entrada consta de un nombre de algoritmo no sensible a mayúsculas/minúsculas y el tamaño de clave por defecto correspondiente (en decimales) separados por ':'. Además, se ignora el espacio en blanco.
Por defecto, esta propiedad no tendrá ningún valor y los proveedores de JDK utilizarán sus propios valores por defecto. Se ignorarán las entradas que contengan un nombre de algoritmo no reconocido. Si el tamaño de la clave por defecto especificada no es un entero decimal analizable, esa entrada también se ignorará.
1. La implantación de DSA KeyPairGenerator del proveedor SUN ya no implanta java.security.interfaces.DSAKeyPairGenerator. Las aplicaciones que convierten el objeto de DSA KeyPairGenerator del proveedor de SUN en un java.security.interfaces.DSAKeyPairGenerator pueden definir la propiedad del sistema "jdk.security.legacyDSAKeyPairGenerator". Si el valor de esta propiedad es 'true', el proveedor de SUN devolverá un objeto de DSA KeyPairGenerator que implanta la interfaz de java.security.interfaces.DSAKeyPairGenerator. Esta implantación antigua utilizará el mismo valor por defecto según lo especificado por javadoc en la interfaz.
Por defecto, esta propiedad no tendrá ningún valor y el proveedor SUN devolverá un objeto de DSA KeyPairGenerator que no implanta la interfaz mencionada anteriormente y, por lo tanto, puede determinar su propio valor por defecto específico del proveedor, como se indica en la clase java.security.KeyPairGenerator, o en la propiedad de sistema 'jdk.security.defaultKeySize' si se define.
JDK-8181048 (no público)

Fecha de caducidad de Java

La fecha de caducidad de 8u151 es el 16 de enero de 2018. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u151) el 16 de febrero de 2018. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u151

Java 8 Update 144 (8u144)

Características principales de la versión

Datos IANA 2017b
JDK 8u144 contiene datos de zona horaria IANA versión 2017b. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Corrección de bug: java.util.zip.ZipFile.getEntry() ahora devuelve siempre la instancia ZipEntry con un nombre de entrada terminado en / para la entrada de directorio
El documento de API java.util.zip.ZipEntry especifica "Una entrada de directorio está definida para que sea una cuyo nombre termine en /". Sin embargo, en versiones de JDK anteriores, java.util.zip.ZipFile.getEntry(String entryName) puede devolver una instancia ZipEntry con nombre de entrada que no termine en / para una entrada de directorio zip existente cuando el argumento transferido entryName no termina en un / y hay una entrada de directorio zip coincidente con el nombre entryName + / en el archivo zip. A partir de esta versión, el nombre de la instancia ZipEntry devuelto de java.util.zip.ZipFile.getEntry() siempre termina en / al mostrar una entrada de directorio ZIP.
Para revertir al comportamiento anterior, establezca la propiedad de sistema jdk.util.zip.ensureTrailingSlash en 'false'.

Este cambio se hizo para corregir una regresión introducida en JDK 8u141 al verificar los archivos JAR firmados y que ha provocado que algunas aplicaciones de Webstart no se pudieran cargar.
Consulte JDK-8184993

Fecha de caducidad de Java

La fecha de vencimiento de 8u144 es el 17 de octubre de 2017. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará del vencimiento de esta versión de JRE (versión 8u144) el 17 de noviembre de 2017. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u144

Java 8 Update 141 (8u141)

Características principales de la versión

Datos IANA 2017b
JDK 8u141 contiene datos de zona horaria IANA versión 2017b. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Cambios de certificado: Se han agregado nuevos certificados Let's Encrypt a las CA raíz
Se ha agregado un nuevo certificado raíz:
ISRG Root X1 alias: letsencryptisrgx1 DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US
JDK-8177539 (no público)
Mejoras del diagnóstico de JMX
La API com.sun.management.HotSpotDiagnostic::dumpHeap se ha modificado para devolver IllegalArgumentException si el nombre de archivo proporcionado no acaba con el sufijo “.hprof”. Las aplicaciones existentes que no proporcionen un nombre de archivo que acabe con la extensión “.hprof”, obtendrán la excepción IllegalArgumentException. En ese caso, las aplicaciones pueden elegir si manejar la excepción o restaurar un comportamiento anterior estableciendo la propiedad de sistema 'jdk.management.heapdump.allowAnyFileSuffix' en true.
JDK-8176055 (no público)
Comprobaciones de seguridad más estrictas durante el procesamiento de los archivos WSDL con la herramienta wsimport
La herramienta wsimport se ha cambiado para no permitir los DTD en las descripciones del servicio web:
- La declaración DOCTYPE no está permitida en los documentos
- Las entidades generales externas no están incluidas por defecto
- Las entidades de parámetros externas no están incluidas por defecto
- Los DTD externos se ignoran por completo
Para restaurar el comportamiento anterior:
- Defina la propiedad del sistema com.sun.xml.internal.ws.disableXmlSecurity en true
- Utilice la opción de la línea de comandos de la herramienta wsimport –disableXmlSecurity
  NOTA: La compatibilidad de JDK 7 y JDK 6 para esta opción en wsimport se proporcionará a través de la publicación de un parche posterior a la actualización de parche crítico de julio
JDK-8182054 (no público)
El elemento HostnameVerifier personalizado permite la extensión SNI
Las versiones anteriores de JDK 8 Update no siempre enviaban la extensión de indicación de nombre de servidor (SNI) en la fase ClientHello de TLS si se había utilizado un verificador de nombre de host personalizado. Este verificador se define mediante el método setHostnameVerifier(HostnameVerifier v) en HttpsURLConnection. La corrección asegura que el nombre del servidor ahora se envía al cuerpo de ClientHello.
Consulte JDK-8144566
Comprobación mejorada de restricciones de algoritmo
Debido a que es necesario restringir el uso de algoritmos de poca seguridad en situaciones en las que son más vulnerables, se han agregado funciones adicionales al configurar las propiedades de seguridad jdk.certpath.disabledAlgorithms y jdk.jar.disabledAlgorithms en el archivo java.security.
jdk.certpath.disabledAlgorithms: la propiedad certpath es la que ha experimentado el mayor cambio. Hasta ahora, estaba limitada a dos tipos de restricciones, ya sea una desactivación completa de un algoritmo por nombre o por el tamaño de la clave al comprobar los certificados, las cadenas de certificados y las firmas de certificado. Esto crea configuraciones sin flexibilidad alguna en su sintaxis. Se han agregado tres nuevas restricciones para proporcionar una mayor flexibilidad a la hora de permitir y rechazar certificados.

"jdkCA" examina la terminación de la cadena de certificados del archivo cacerts. En el caso de "SHA1 jdkCA". La sintaxis de SHA1's se revisa en la cadena de certificados pero, para que se pueda rechazar, la cadena deberá terminar en un anclaje de confianza marcado en el almacén de claves cacerts. Esto resulta útil para las organizaciones que tienen su propia CA privada en la que confían, ya que utiliza SHA1 con su propio anclaje de confianza, pero que quieren bloquear las cadenas de certificados ancladas con una CA pública que utiliza SHA1.

"denyAfter" comprueba si la fecha proporcionada es anterior a la fecha actual o a la fecha de PKIXParameter. En el caso de "SHA1 denyAfter 2018-01-01", si es anterior a 2018, se podrá utilizar un certificado con SHA1, pero después de esa fecha, se rechazará el certificado. Se puede utilizar para una política en una organización que esté eliminando gradualmente un algoritmo con una fecha de extinción. Para archivos JAR firmados, la fecha se compara con el registro de hora de TSA. La fecha se especifica en GMT.

"usage" examina el algoritmo especificado para una sintaxis concreta. Se puede utilizar cuando no resulte práctico desactivar un algoritmo para todas las sintaxis. Se pueden especificar tres tipos de sintaxis:
- 'TLSServer' restringe el algoritmo en las cadenas de certificado del servidor TLS cuando la autenticación del servidor se realiza como cliente.
- 'TLSClient' restringe el algoritmo en las cadenas de certificados del cliente TLS cuando la autenticación del cliente se realiza como servidor.
- 'SignedJAR' restringe los algoritmos en los certificados de los archivos JAR firmados. El tipo de uso sigue a la palabra clave y se puede especificar más de un tipo de uso con un delimitador de espacio en blanco.
  Por ejemplo, "SHA1 usage TLSServer TLSClient" no permitirá certificados SHA1 para las operaciones TLSServer y TLSClient, pero se permitirá SignedJars
Todas estas restricciones se pueden combinar para restringir un algoritmo cuando esté delimitado por '&'. Por ejemplo, para desactivar las cadenas de certificados SHA1 que terminan en anclajes de confianza marcados solo por operaciones TLSServer, la restricción sería "SHA1 jdkCA & usage TLSServer".

jdk.jar.disabledAlgorithms: se ha agregado una restricción adicional a esta propiedad .jar para restringir los algoritmos de manifiesto JAR.

"denyAfter" comprueba las restricciones del algoritmo en los algoritmos de resumen de manifiesto en un archivo JAR firmado. La fecha proporcionada en la restricción se compara con el registro de hora de TSA en el archivo JAR firmado. Si no hay ningún registro de hora, el registro de hora es posterior o coincide con la fecha especificada, el archivo JAR firmado se trata como no firmado. Si el registro de hora es anterior a la fecha especificada, .jar funcionará como un archivo JAR firmado. La sintaxis para restringir SHA1 en los archivos JAR firmados después del 1 de enero de 2018 es: "SHA1 denyAfter 2018-01-01". La sintaxis es la misma que la de la propiedad certpath, pero esta propiedad no realizará la comprobación del certificado.
Consulte JDK-8176536

Fecha de caducidad de Java

La fecha de caducidad de 8u141 es el 17 de octubre de 2017. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u141) el 17 de noviembre de 2017. Una vez se haya cumplido cualquiera de las condiciones (que la nueva versión esté disponible o que se haya alcanzado la fecha de caducidad), el JRE enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u141

Java 8 Update 131 (8u131)

Características principales de la versión

IANA Data 2016j
JDK 8u131 contiene datos de zona horaria IANA versión 2016j. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Corrección de bug: Introducción del nuevo modelo de ordenación de ventanas
En la plataforma OS X, el marco de AWT utilizaba servicios nativos para implantar la relación principal/secundario en las ventanas. Esto causaba algunos efectos visuales negativos, especialmente en entornos con varios monitores. Para evitar las desventajas de este enfoque, se ha introducido el nuevo modelo de ordenación de ventanas, implantado en su totalidad en la capa de JDK. A continuación, se detallan sus principios fundamentales:
- Una ventana se debe colocar encima de su ventana principal más cercana.
- Si una ventana tiene varias ventanas secundarias, todas ellas se deben colocar en la misma capa y la ventana de la cadena de ventanas activa sobre sus hermanos.
- No se podrán ordenar ventanas con estado iconificado o cuando si se está procesando su transición a estado iconoficado.
Estas reglas se aplican a todos los marcos o diálogos de la jerarquía de ventanas que contengan la ventana en la que se está trabajando. Consulte JDK-8169589
Corrección de bug: Corrección de IllegalArgumentException en establecimiento de comunicación TLS
Un reciente problema derivado de la corrección JDK-8173783 puede causar problemas en algunos servidores de TLS. El problema tiene su origen en una excepción IllegalArgumentException devuelta por el código de establecimiento de comunicación TLS:

java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves

Este problema puede producirse si el servidor no admite la criptografía de curva elíptica para gestionar un campo de extensión de nombre de curva elíptica (si está presente). Se recomienda que los usuarios actualicen a esta versión. Por defecto, las versiones de JDK 7 Update y familias JDK posteriores incluyen el proveedor de seguridad SunEC, que proporciona soporte para criptografía de curva elíptica. Estas versiones no se verán afectadas a menos que se modifiquen los proveedores de seguridad. Consulte JDK-8173783
Se ha agregado MD5 a la propiedad de seguridad jdk.jar.disabledAlgorithms
Esta versión de JDK incorpora una restricción nueva sobre cómo se verifican los archivos JAR firmados con MD5. Si el archivo JAR firmado utiliza MD5, las operaciones de verificación de firma ignorarán la firma y tratarán al JAR como si no la tuviera. Esto podría ocurrir potencialmente en los siguientes tipos de aplicaciones que utilizan archivos JAR firmados:
- Applets o aplicaciones Web Start
- Aplicaciones independientes o de servidor ejecutadas con SecurityManager activado y que se configuran con un archivo de políticas que otorga permisos en función de los firmantes del código del JAR.
La lista de algoritmos desactivados se controla mediante la propiedad de seguridad, jdk.jar.disabledAlgorithms en el archivo java.security. Esta propiedad contiene una lista de los algoritmos desactivados y tamaños de clave para los archivos JAR firmados mediante cifrado.

Para comprobar si se ha utilizado un algoritmo o clave débil para firmar un archivo JAR, se puede utilizar el binario jarsigner incluido en este JDK. La ejecución de "jarsigner -verify" en un archivo JAR firmado con una clave o algoritmo débiles imprimirá más información sobre el algoritmo o clave desactivados.

Por ejemplo, para comprobar un archivo JAR denominado test.jar, utilice este comando:

jarsigner -verify test.jar

Si el archivo de este ejemplo se ha firmado con un algoritmo de firma débil como MD5withRSA, se obtendría el siguiente resultado:

The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled. Re-run jarsigner with the -verbose option for more details.

Se pueden mostrar más detalles mediante la opción detallada:

jarsigner -verify -verbose test.jar

Se obtendría el siguiente resultado:
```
 - Signed by "CN=weak_signer" Digest algorithm: MD5 (weak) Signature algorithm: MD5withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key 
```
Para abordar el problema, el archivo JAR se debera volver a firmar con un tamaño de clave o algoritmo más seguro. También puede revertir las restricciones eliminando los tamaños de clave o algoritmos débiles de la propiedad de seguridad jdk.jar.disabledAlgorithms, pero no se recomienda utilizar esta opción. Antes de volver a firmar los archivos JAR afectados, deberá eliminar las firmas existentes del archivo JAR. Para ello, puede utilizar la utilidad zip de la siguiente forma:

zip -d test.jar 'META-INF/.SF' 'META-INF/.RSA' 'META-INF/*.DSA'

Consulte periódicamente Oracle JRE and JDK Cryptographic Roadmap en http://java.com/cryptoroadmap para conocer las restricciones planificadas en los archivos JAR firmados y otros componentes de seguridad. JDK-8171121 (no público)
Nueva propiedad de sistema para controlar el almacenamiento en caché de conexión HTTP que utilice mecanismo SPNEGO.
Se ha introducido una nueva propiedad del sistema específica de implantación de JDK para controlar el almacenamiento en caché de conexiones HTTP que utilicen el mecanismo SPNEGO (Negotiate/Kerberos). El almacenamiento en caché de conexiones HTTP que utilicen el mecanismo SPNEGO sigue activado por defecto por lo que, si no se especifica la propiedad concreta, no se modificará el comportamiento. Al conectarse a un servidor HTTP que utilice el mecanismo SPNEGO para negociar la autenticación, y si la conexión y la autenticación con el servidor son correctas, la información de autenticación se almacenará en caché y se reutilizará para establecer más conexiones al mismo servidor. Además, la conexión a un servidor HTTP que utilice SPNEGO normalmente implica mantener activa la conexión subyacente y reutilizarla para futuras solicitudes al mismo servidor. En algunas aplicaciones, puede que sea recomendable desactivar todo el almacenamiento en caché del protocolo HTTP con mecanismo SPNEGO (Negotiate/Kerberos) para forzar la solicitud de una nueva autenticación con cada una de las nuevas solicitudes al servidor.

Con este cambio, ahora proporcionamos una nueva propiedad de sistema que permite controlar la política de almacenamiento en caché para las conexiones HTTP que utilicen el mecanismo SPNEGO. Si está definida jdk.spnego.cache y se evalúa en false, se desactivará todo el almacenamiento en caché para las conexiones HTTP que utilicen el mecanismo SPNEGO. Aun así, la definición de esta propiedad de sistema en false puede provocar efectos secundarios no deseados:
- El rendimiento de las conexiones HTTP que utilicen el mecanismo SPNEGO se puede ver gravemente afectado, ya que la conexión tendrá que volver a autenticarse con cada nueva solicitud, por lo que se necesitarán varios intercambios de comunicación con el servidor.
- Se tendrán que volver a obtener credenciales para cada nueva solicitud, lo que, en función de la disponibilidad de la autenticación transparente y de la implementación de autenticador global, puede resultar en una ventana emergente pidiendo las credenciales al usuario con cada nueva solicitud.
JDK-8170814 (no público)
Nueva propiedad de sistema para controlar el almacenamiento en caché de conexiones HTTP que utilicen mecanismo NTLM.
Se ha introducido una nueva propiedad del sistema específica de implantación de JDK para controlar el almacenamiento en caché de conexiones HTTP que utilicen NTLM. El almacenamiento en caché para la conexión HTTP que utilice el mecanismo NTLM sigue activado por defecto por lo que, si no se especifica explícitamente la propiedad, no habrá ningún cambio de comportamiento. En algunas plataformas, la implantación de conexiones HTTP que utilicen NTLM en el JDK permite la autenticación transparente, donde se utilizan las credenciales del usuario del sistema en el nivel de sistema. Si la autenticación transparente no está disponible o no es correcta, el JDK solo podrá obtener credenciales de un autenticador global. Si la conexión al servidor es correcta, la información de autenticación se almacenará en caché y se reutilizará para establecer más conexiones al mismo servidor. Además, la conexión a un servidor HTTP que utilice NTLM suele implicar mantener activa la conexión subyacente y reutilizarla para futuras solicitudes al mismo servidor. En algunas aplicaciones, puede que sea recomendable desactivar todo el almacenamiento en caché del protocolo HTTP con mecanismo NTLM para forzar la solicitud de una nueva autenticación con cada una de las nuevas solicitudes al servidor.

Con este cambio, ahora proporcionamos una nueva propiedad de sistema que permite controlar la política de almacenamiento en caché para las conexiones HTTP que utilicen el mecanismo NTLM. Si está definida jdk.ntlm.cache y se evalúa en false, se desactivará todo el almacenamiento en caché para las conexiones HTTP que utilicen el mecanismo NTLM. Aun así, la definición de esta propiedad de sistema en false puede provocar efectos secundarios no deseados:
- El rendimiento de las conexiones HTTP que utilicen el mecanismo NTLM se puede ver gravemente afectado, ya que la conexión tendrá que volver a autenticarse con cada nueva solicitud, por lo que se necesitarán varios intercambios de comunicación con el servidor.
- Se tendrán que volver a obtener credenciales para cada nueva solicitud, lo que, en función de la disponibilidad de la autenticación transparente y de la implementación de autenticador global, puede resultar en una ventana emergente pidiendo las credenciales al usuario con cada nueva solicitud.
JDK-8163520 (no público)
Nueva versión de VisualVM
VisualVM 1.3.9 se publicó el 4 de octubre de 2016http://visualvm.github.io/relnotes.html y se ha integrado en 8u131. Consulte JDK-8167485

Fecha de caducidad de Java

La fecha de caducidad para 8u131 es el 18 de julio de 2017. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u131) el 18 de agosto de 2017. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Asesor de actualización de parche crítico de Oracle Java SE. Para acceder a una lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u131.

» Notas de la versión 8u131

Java 8 Update 121 (8u121)

Características principales de la versión

Datos IANA 2016i
JDK 8u101 contiene datos de zona horaria IANA versión 2016i. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Corrección de bug: En el sistema operativo OS X 10.12 Sierra, el desplazamiento por el pad es muy rápido
El método MouseWheelEvent.getWheelRotation() ha devuelto eventos NSEvent deltaX/Y redondeados en Mac OS X. La versión macOS Sierra 10.12 más reciente genera valores NSEvent deltaX/Y muy pequeños, de modo que al sumarlos y redondearlos el valor obtenido de MouseWheelEvent.getWheelRotation() es muy grande. La corrección JDK-8166591 acumula NSEvent deltaX/Y y el método MouseWheelEvent.getWheelRotation() devuelve valores que no son igual a cero solo si el valor acumulado excede el umbral y el valor de cero. Esto cumple la especificación MouseWheelEvent.getWheelRotation(): "Devuelve el número de 'clics' que ha rotado la rueda del mouse, como un valor entero. Si el ratón tiene una rueda de alta resolución, se puede realizar una rotación parcial. En este caso, el método devuelve cero hasta que se haya acumulado un "clic" completo". Para los valores de rotación de rueda precisos, utilice en su lugar el método MouseWheelEvent.getPreciseWheelRotation(). Consulte JDK-8166591
Mejora de la seguridad por defecto de EC en el JDK
Para mejorar la seguridad de la criptografía de EC, las claves de EC de menos de 224 bits se han desactivado en el proceso de ruta de certificación (mediante la propiedad de seguridad jdk.certpath.disabledAlgorithms) y las conexiones SSL/TLS (mediante la propiedad de seguridad jdk.tls.disabledAlgorithms) en JDK. Las aplicaciones pueden actualizar esta restricción en las propiedades de seguridad y permitir claves de menor tamaño si es necesario (por ejemplo, "EC keySize < 192"). Las curvas de EC de menos de 256 bits se eliminan de la implementación SSL/TLS en JDK. La nueva propiedad de sistema jdk.tls.namedGroups define una lista de curvas con nombre activadas para los conjuntos de cifrado de EC en orden de preferencia. Si una aplicación necesita para personalizar las curvas de EC activadas por defecto o la preferencia de curvas, actualice la propiedad del sistema según corresponda. Por ejemplo:
```
 jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" 
```
Tenga en cuenta que las curvas de EC personalizadas o activadas por defecto siguen las restricciones de algoritmo. Por ejemplo, las curvas de EC personalizadas no pueden volver a activar las claves de EC desactivadas que hayan definido las propiedades de seguridad de Java. Consulte JDK-8148516
Novedad --opción allow-script-in-comments para javadoc
La herramienta javadoc rechazará todas las instancias de código de JavaScript en los comentarios de documentación de javadoc y opciones de la línea de comandos, a menos que se especifique la opción --allow-script-in-comments en la línea de comandos. Con la opción --allow-script-in-comments, la herramienta javadoc conservará el código de JavaScript en los comentarios de documentación y en las opciones de la línea de comandos. Se producirá un error en la herramienta javadoc si se detecta código de JavaScript y no se ha definido la opción de la línea de comandos.
JDK-8138725 (no público)
Aumentar la longitud mínima de la clave a 1024 para firmas XML
El modo de validación segura de la implantación de firmas XML se ha mejorado para restringir las claves RSA y DSA para que tengan menos de 1024 bits por defecto, puesto que ya no son los suficientemente seguras. Además, se ha agregado una nueva propiedad de seguridad denominada jdk.xml.dsig.SecureValidationPolicy al archivo java.security y se puede utilizar para controlar las distintas restricciones aplicadas cuando se activa el modo de validación segura. El modo de validación segura se activa definiendo la propiedad de firma xml org.jcp.xml.dsig.secureValidation en true con el método javax.xml.crypto.XMLCryptoContext.setProperty o ejecutando el código con SecurityManager. Si se genera una firma XML o se valida con una clave RSA o DSA que no sea lo suficientemente segura, se emitirá una excepción XMLSignatureException con el mensaje "Las claves RSA con menos de 1024 bits no se pueden utilizar si está activada la validación segura" o "Las claves DSA con menos de 1024 bits no se pueden utilizar si está activada la validación segura".
JDK-8140353 (no público)
Restringir certificados con claves DSA de menos de 1024 bits
Las claves DSA de menos de 1024 bits no son lo suficientemente seguras y se deben restringir al crear y validar la ruta de certificación. Es decir, las claves DSA de menos de 1024 bits se desactivan por defecto agregando "DSA keySize < 1024" a la propiedad de seguridad "jdk.certpath.disabledAlgorithms". Las aplicaciones pueden actualizar esta restricción en la propiedad de seguridad ("jdk.certpath.disabledAlgorithms") y permitir tamaños de clave más pequeños si realmente es necesario (por ejemplo, "DSA keySize < 768"). JDK-8139565 (no público)
Se han agregado más comprobaciones al análisis de codificación DER
Se han agregado más comprobaciones al código de análisis de codificación DER para detectar diversos errores de codificación. Además, las firmas con codificación de longitud no definida ahora generarán una excepción IOException durante la fase de análisis. Tenga en cuenta que las firmas generadas con proveedores por defecto de JDK no se verán afectadas por este cambio. JDK-8168714 (no público)
Restricciones de acceso adicionales para URLClassLoader.newInstance
Los cargadores de clase creados por los métodos java.net.URLClassLoader.newInstance se pueden utilizar para cargar clases de una lista de determinadas URL. Si el código de llamada no tiene acceso a una o más de las direcciones URL y los artefactos de URL a los que se puede acceder no contienen la clase necesaria, se devolverá una excepción ClassNotFoundException o similar. Hasta ahora, si se denegaba el acceso a una URL, se generaba una excepción SecurityException. Si fuera necesario volver a la situación anterior, este cambio se puede desactivar definiendo la propiedad del sistema jdk.net.URLClassPath.disableRestrictedPermissions. JDK-8151934 (no público)
Nueva propiedad configurable en logging.properties java.util.logging.FileHandler.maxLocks
Se ha agregado una nueva propiedad configurable "java.util.logging.FileHandler.maxLocks" a java.util.logging.FileHandler. Esta nueva propiedad de registro se puede definir en el archivo de configuración de registro y permite configurar el número máximo de bloqueos simultáneos un archivo log FileHandler puede manejar. El valor por defecto es 100. En un entorno altamente concurrente en el que varias (más de 101) aplicaciones de cliente autónomas utilizan la API de registro de JDK con FileHandler simultáneamente, puede ocurrir que se alcance el límite por defecto de 100, lo que puede llevar a fallos al adquirir los bloqueos de archivo de FileHandler y causar la emisión de una excepción de E/S. En ese caso, la nueva propiedad de registro se puede utilizar para aumentar el número máximo de bloqueos antes de desplegar la aplicación. Si no se sustituye, el valor por defecto de maxLocks (100) permanece igual. Consulte la documentación de la API de java.util.logging.LogManager y java.util.logging.FileHandler para obtener más información. Consulte JDK-8153955

Notas

Mejora en la protección para carga de clases remotas por JNDI

La carga de clases remotas mediante fábricas de objetos JNDI almacenados en los servicios de directorio y de nomenclatura está desactivada por defecto. Para activar la carga de clases remotas mediante el registro de RMI o el proveedor de servicios de nomenclatura COS, defina la siguiente propiedad del sistema en la cadena "true", según corresponda:


 com.sun.jndi.rmi.object.trustURLCodebase com.sun.jndi.cosnaming.object.trustURLCodebase

JDK-8158997 (no público)

jarsigner -verbose -verify debe imprimir los algoritmos utilizados para firmar el jar

La herramienta jarsigner se ha mejorado para mostrar los detalles de los algoritmos y claves que se utilizan para generar un archivo JAR firmado y proporciona también una indicación si alguno de ellos no se considera lo suficientemente seguro.

En concreto, si se llama a "jarsigner -verify -verbose filename.jar", aparece una sección distinta que muestra información de la firma y el registro de hora (si lo hay) en el archivo JAR firmado, incluso si se trata como no firmado por diversos motivos. Si se considera que un algoritmo o clave que se utilice no es lo suficientemente seguro, como se indica en la propiedad de seguridad jdk.jar.disabledAlgorithms, aparecerá marcado como "(no seguro)".

Por ejemplo:


 - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key

Consulte JDK-8163304

Problemas conocidos

javapackager and fx:deploy agrupan todo el JDK en lugar de JRE

Hay un bug conocido en Java Packager para Mac donde todo el JDK se incluirá con el paquete de aplicación lo que resultará en un grupo inusualmente grandes. La solución es utilizar la opción de agrupación -Bruntime. Por ejemplo: -Bruntime=JavaAppletPlugin.plugin donde el JavaAppletPlugin.plugin para el grupo que JRE quiere está ubicado en el directorio actual. Consulte JDK-8166835

La instalación de Java fallará para los usuarios no administradores que tengan UAC desactivado

La instalación de Java en Windows fallará sin advertencia ni aviso alguno para los usuarios no administradores que tengan el control de acceso de usuario (UAC). El instalador dejará un directorio, jds<número>.tmp, en el directorio %TEMP%.
JDK-8161460 (no público)

Nuevas funciones

Se ha agregado la propiedad de seguridad para configurar el modo de validación seguro de firma XML

Se ha agregado una nueva propiedad de seguridad denominada jdk.xml.dsig.secureValidationPolicy que permite configurar restricciones concretas que se aplican cuando está activado el modo de firma XML. El valor por defecto para esta propiedad en el archivo de configuración java.security es:


 jdk.xml.dsig.secureValidationPolicy=\ disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\ maxTransforms 5,\ maxReferences 30,\ disallowReferenceUriSchemes file http https,\ noDuplicateIds,\ noRetrievalMethodLoops

Consulte la definición de la propiedad en el java.security para obtener más información. Consulte JDK-8151893

Configuración de filtro de serialización

El filtrado de serialización introduce un nuevo mecanismo que permite filtrar los flujos de datos de serialización de objetos entrantes para mejorar seguridad y solidez. Cada ObjectInputStream aplica un filtro, si se ha configurado, al contenido del flujo durante la anulación de la serialización. Los filtros se definen utilizando una propiedad del sistema o una propiedad de seguridad configurada. El valor de los patrones "jdk.serialFilter" se describe en JEP 290 Serialization Filtering y en <JRE>/lib/security/java.security. Las acciones de filtro se registran en el registrador 'java.io.serialization', si está activado. Consulte JDK-8155760

Mejora en la comprobación de restricción RMI

El registro de RMI y la recopilación de desechos distribuidos utilizan los mecanismos descritos en JEP 290 Serialization Filtering para mejorar la seguridad del servicio. El registro de RMI y DGC incluyen filtros de lista blanca para las clases que normalmente se espera que utiliza cada servicio. Se pueden configurar patrones de filtro adicionales utilizando una propiedad del sistema o una propiedad de seguridad. La sintaxis de patrones de propiedad "sun.rmi.registry.registryFilter" y "sun.rmi.transport.dgcFilter" está descrita en JEP 290 y en <JRE>/lib/security/java.security. JDK-8156802 (no público)

Agregue el mecanismo para que los CA raíz por defecto no estén sujetos a restricciones de algoritmos

En el archivo java.security, se agrega una restricción adicional denominada "jdkCA" a la propiedad jdk.certpath.disabledAlgorithms. Esta restricción prohíbe el algoritmo especificado solo si el algoritmo se usa en una cadena de certificados que termina en un anclaje de confianza marcado en el almacén de claves lib/security/cacerts. Si no se ha definido la restricción jdkCA, todas las cadenas que usen el algoritmo especificado están restringidas. jdkCA solo puede usarse una vez en una expresión DisabledAlgorithm. Ejemplo: Para aplicar esta restricción a los certificados SHA-1, se debe incluir lo siguiente: SHA1 jdkCA
Consulte JDK-8140422

Fecha de caducidad de Java

8u121 caduca el 18 de abril de 2017. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u121) el 18 de mayo de 2017. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u121

Java 8 Update 111 (8u111)

Características principales de la versión

Datos IANA 2016f
JDK 8u111 contiene datos de zona horaria IANA versión 2016f. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE. Consulte JDK-8159684.
Cambios de certificado: Nueva CA raíz para firma de código JCE
Para poder soportar longitudes de clave más largas y algoritmos de firma de mayor seguridad, se ha creado una nueva autoridad de certificación raíz para firma de código de proveedor de JCE y se ha agregado su certificado a Oracle JDK. Los nuevos certificados de firma de código de proveedor de JCE emitidos desde esta CA se utilizarán para firmar a los proveedores de JCE de ahora en delante. Por defecto, las solicitudes nuevas de certificados de firma de código de proveedor de JCE se emitirán desde esta CA.

Los certificados existentes de la raíz de firma de código de proveedor de JCE actual seguirán sirviendo para la validación. Aun así, esta CA raíz se puede desactivar en cualquier momento en un futuro. Le recomendamos solicitar los nuevos certificados y volver a firmar los JAR de proveedor existentes. Para obtener más información sobre el proceso de firma de proveedor de JCE, consulte la documentación sobre cómo implantar un proveedor en la arquitectura de cifrado de Java. JDK-8141340 (no público)
Servicios del menú Servicio
La gestión del ciclo de vida de los componentes de menú de AWT ha generado problemas en determinadas plataformas. Esta corrección mejora el estado de sincronización entre los menús y sus contenedores. JDK-8158993 (no público)
Desactivación de la autenticación básica para canal HTTPS
En determinados entornos, hay algunos esquemas de autenticación que puede que no se quieran conectar mediante HTTPS. Si este es el caso, el esquema de autenticación básica se desactiva por defecto en el tiempo de ejecución de Oracle Java si se agrega Básica a la propiedad de red jdk.http.auth.tunneling.disabledSchemes. A partir de ahora, los proxies que necesitan autenticación básica al configurar un canal para HTTPS ya no serán los adecuados por defecto. Si es necesario, este esquema de autenticación se puede volver a activar si se elimina Básica de la propiedad de red jdk.http.auth.tunneling.disabledSchemes o se define una propiedad del sistema del mismo nombre en "" (vacío) en la línea de comandos. Además, las propiedades de red jdk.http.auth.tunneling.disabledSchemes y jdk.http.auth.proxying.disabledSchemes y las propiedades del sistema del mismo nombre, se puede utilizar para desactivar otros esquemas de autenticación que puedan estar activos si se configura un canal para HTTPS se envía mediante proxy HTTP normal, respectivamente. JDK-8160838 (no público)
Restricción de los JAR firmados con claves y algoritmos débiles
Esta versión de JDK introduce nuevas restricciones sobre cómo se verifican los archivos JAR firmados. Si el archivo JAR firmado utiliza un algoritmo desactivado o un tamaño de clave inferior a la longitud mínima, las operaciones de verificación de firma ignorarán la firma y tratarán al JAR como si no la tuviera. Esto podría ocurrir potencialmente en los siguientes tipos de aplicaciones que utilizan archivos JAR firmados:
1. Applets o aplicaciones Web Start
2. Aplicaciones independientes o de servidor ejecutadas con SecurityManager activado y que se configuran con un archivo de políticas que otorga permisos en función de los firmantes del código del JAR.

La lista de algoritmos desactivados se controla mediante una nueva propiedad de seguridad, jdk.jar.disabledAlgorithms, en el archivo java.security. Esta propiedad contiene una lista de los algoritmos desactivados y tamaños de clave para los archivos JAR firmados mediante cifrado.

En esta versión se han restringido los siguientes tamaños de clave y algoritmos:
1. MD2 (en el resumen o en el algoritmo de firma)
2. Claves de RSA de menos de 1024 bits
NOTA: El plan es restringir las firmas MD5 en los JAR firmados en la CPU de abril de 2017.

Para comprobar si se ha utilizado un algoritmo o clave débil para firmar un archivo JAR, se puede utilizar el binario jarsigner incluido en este JDK. La ejecución de jarsigner -verify -J-Djava.security.debug=jar en un archivo JAR firmado claves o algoritmos débiles imprimirá más información sobre el algoritmo o clave desactivados.

Por ejemplo, para comprobar un archivo JAR denominado test.jar, utilice este comando:
jarsigner -verify -J-Djava.security.debug=jar test.jar

Si el archivo de este ejemplo se ha firmado con un algoritmo de firma débil como MD2withRSA, se obtendría el siguiente resultado:
jar: beginEntry META-INF/my_sig.RSA
jar: processEntry: processing block
jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA
jar: done with meta!

El comando jarsigner actualizado saldrá con la siguiente advertencia impresa en el resultado estándar:
"No se puede analizar ni verificar la firma. El archivo jar se tratará como si no estuviera firmado. Puede que el archivo jar se haya firmado con un algoritmo débil que ahora está desactivado. Para obtener más información, vuelva a ejecutar jarsigner con la depuración activada (-J-Djava.security.debug=jar)"

Para solucionar el problema, se debe volver a firmar el archivo JAR con un tamaño de clave o algoritmo de mayor seguridad. También puede revertir las restricciones eliminando los tamaños de clave o algoritmos débiles de la propiedad de seguridad jdk.jar.disabledAlgorithms, pero no se recomienda utilizar esta opción. Antes de volver a firmar los archivos JAR afectados, deberá eliminar las firmas existentes del JAR. Para ello, puede utilizar la utilidad zip de la siguiente forma:

zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'

Consulte periódicamente Oracle JRE and JDK Cryptographic Roadmap en http://java.com/cryptoroadmap para conocer las restricciones planificadas en los archivos JAR firmados y otros componentes de seguridad. En concreto, el plan actual contempla restringir las firmas MD5 en los archivos JAR firmados para la CPU de abril de 2017.

Para saber si unos archivos JAR se han firmado con MD5, agregue MD5 a la propiedad de seguridad jdk.jar.disabledAlgorithms. Ejemplo:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

A continuación, ejecute jarsigner -verify -J-Djava.security.debug=jar en los archivos JAR como se ha descrito anteriormente.
JDK-8155973 (no público)
Se ha agregado un mensaje de advertencia al cuadro de diálogo de autenticador de despliegue
Se ha agregado una advertencia al cuadro de diálogo de autenticación de plugins en los casos en los que se utiliza la autenticación básica HTTP (las credenciales se envían sin cifrar) al utilizar un proxy o si no se están utilizando los protocolos SSL/TLS:
"ADVERTENCIA: El esquema de autenticación básica transmitirá perfectamente las credenciales en texto claro. ¿Seguro que quiere hacerlo?"
JDK-8161647 (no público)

Problemas conocidos

Algunos eventos no están disponibles en los registros de JFR en Windows

Los siguientes eventos no están disponibles en los registros de JFR en Windows para la versión 8u111:

hotspot/jvm/os/processor/cpu_load
os/processor/context_switch_rate

Esto es debido a la modificación del JDK-8063089 que se introdujo en 8u111 con los cambios para JDK-8162419. La corrección para JDK-8063089 no se podía incluir en la versión 8u111. Estará disponible en la siguiente versión de 8u111 BPR y en la próxima versión pública.
JDK-8063089 (no público)

JVM devuelve NullPointerExceptions en macOS Sierra 10.12

En macOS Sierra 10.12, si un usuario pulsa teclas modificadoras (como Comando, Mayúsculas o Alt) mientras se está ejecutando un applet en el navegador, aparecerá un cuadro de error con el nombre "Error interno". También aparecerá el icono "ejec." en el Dock de macOS. El usuario puede cerrar el applet o intentar ejecutarlo de nuevo, esta vez sin pulsar una clave de modificador. Consulte JDK-8165867.

Fecha de caducidad de Java

La fecha de caducidad de 8u111 es el 17 de enero de 2017. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u111) el 17 de febrero de 2017. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u111

Java 8 Update 101 (8u101)

Características principales de la versión

Datos IANA 2016d
JDK 8u101 contiene datos de zona horaria IANA versión 2016d. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE. Consulte JDK-8151876.
Cambios de certificado
Se han agregado nuevos certificados DTrust a las CA raíz
Se han agregado dos nuevos certificados raíz:
- D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE
- D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE
Consulte JDK-8153080

Se han agregado nuevos certificados Iden a las CA raíz
Se han agregado tres nuevos certificados raíz:
- IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US
- IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US
- IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
Consulte JDK-8154757

Se ha eliminado la CA raíz de Comodo
El certificado de la CA raíz "UTN - DATACorp SGC" de Comodo se ha eliminado del archivo cacerts. Consulte JDK-8141540

Se ha eliminado la CA de Sonera Class1
El certificado de la CA raíz "Sonera Class1 CA" se ha eliminado del archivo cacerts. Consulte JDK-8141276.
Mejora del control de acceso a javax.rmi.CORBA.ValueHandler
La clase javax.rmi.CORBA.Util proporciona métodos que pueden utilizar los stubs y enlaces para realizar operaciones comunes. También actúa como una fábrica para elementos ValueHandler. La interfaz javax.rmi.CORBA.ValueHandler proporciona servicios que permiten soportar la lectura y escritura de tipos de valor en flujos GIOP. Se ha mejorado el conocimiento de seguridad de estas utilidades con la introducción de un permiso java.io.SerializablePermission("enableCustomValueHanlder"). Se utiliza para establecer una relación de confianza entre los usuarios de las API javax.rmi.CORBA.Util y javax.rmi.CORBA.ValueHandler.

El permiso necesario es "enableCustomValueHandler" SerializablePermission. Se está ejecutando código de terceros con un SecurityManager instalado; pero, dado que no cuenta con el nuevo permiso al llamar a Util.createValueHandler(), fallará con la excepción AccessControlException.

Este comportamiento de comprobación de permisos puede sustituirse en JDK8u y versiones anteriores. Para hacerlo, defina una propiedad de sistema "jdk.rmi.CORBA.allowCustomValueHandler".

Así, en las aplicaciones externas que llaman de forma explícita a javax.rmi.CORBA.Util.createValueHandler se debe realizar un cambio de configuración para que funcionen cuando se instale un SecurityManager y no se cumpla ninguno de los dos requisitos siguientes:
1. SecurityManager no ha otorgado el permiso java.io.SerializablePermission("enableCustomValueHanlder").
2. En el caso de las aplicaciones que se ejecuten en la versión JDK8u y en versiones anteriores, la propiedad del sistema jdk.rmi.CORBA.allowCustomValueHandler no se ha definido o se ha definido con un valor "false" (no sensible a mayúsculas/minúsculas).
El error tipográfico de "enableCustomValueHanlder" se corregirá en las versiones de octubre de 2016. En dichas versiones de JDK y en las posteriores, "enableCustomValueHandler" será el valor de SerializationPermission correcto que deberá utilizar.
JDK-8079718 (no público)
Se ha agregado soporte a jarsigner para especificar el algoritmo hash de registro de hora
Se ha agregado una nueva opción -tsadigestalg a jarsigner para especificar el algoritmo de síntesis de mensaje que se utiliza para generar la marca del mensaje que enviar al servidor de TSA. En las versiones anteriores de JDK, el algoritmo digest de mensaje utilizado era SHA-1. Si no se ha especificado esta nueva opción, se utilizará SHA-256 en las actualizaciones de JDK 7 y las versiones posteriores de la familia JDK. En las actualizaciones de JDK 6, SHA-1 seguirá siendo el valor por defecto, pero se imprimirá una advertencia en el flujo de salida estándar. Consulte JDK-8038837
El almacén de claves MSCAPI puede manejar certificados con el mismo nombre
El almacén de claves de Java SE no permite que los certificados tengan el mismo alias. Aun así, en Windows, varios certificados almacenados en un almacén de claves podrán tener nombres descriptivos que no sean únicos. La corrección de JDK-6483657 posibilita utilizar dichos certificados con nombres no únicos mediante la API Java convirtiendo artificialmente los alias visibles en únicos. Tenga en cuenta que esta corrección no permite crear certificados con el mismo nombre con la API Java. Solo permite trabajar con certificados del mismo nombre que se hubieran agregado al almacén de claves mediante herramientas de terceros. Se sigue recomendando no diseñar varios certificados que tengan el mismo nombre. En concreto, la siguiente frase no se eliminará de la documentación de Java:
"Para evitar problemas, se recomienda no utilizar alias en un almacén de claves cuya única diferencia en el nombre sea el uso de mayúscula/minúscula".
Consulte JDK-6483657.
Los métodos de la API de Deployment Toolkit ya no instalarán JRE
La API de Deployment Toolkit installLatestJRE() y los métodos installJRE(requestedVersion) de deployJava.js, así como el método install() de dtjava.js, ya no instalan el JRE. Si la versión de Java de un usuario está por debajo de la línea base de seguridad, redirige al usuario a java.com para obtener un JRE actualizado. JDK-8148310 (no público)
DomainCombiner ya no consultará en la política de tiempo de ejecución los objetos ProtectionDomain estáticos al combinar objetos ProtectionDomain
Las aplicaciones que utilizan objetos ProtectionDomain estáticos (creados con el constructor de 2 argumentos) con un juego insuficiente de permisos ahora pueden recibir una excepción AccessControlException con esta corrección. Deben sustituir los objetos ProtectionDomain estáticos por dinámicos (utilizando el constructor de 4 argumentos) cuyo juego de permiso se ampliará mediante la política actual, o bien crear el objeto ProtectionDomain estático con todos los permisos necesarios. JDK-8147771 (no público)

Problemas conocidos

Internet Explorer (IE) no reconoce JRE 8u101 al utilizar ID de clase estática

Si se utiliza un ID de clase estática para iniciar un applet o aplicación de inicio web con JRE 8u101, los usuarios obtendrán una cuadro de diálogo no deseado que indica que o utilizan la última versión de JRE o deberán cancelar la operación de inicio, incluso si tienen instalada y están utilizando la versión más reciente de JRE (JRE 8u101). Este caso concreto solo ocurre en Windows y IE.

No se recomienda utilizar ID de clase estática para la selección de versión de JRE (a partir de JDK 5u6, Diciembre de 2005) según http://www.oracle.com/technetwork/java/javase/family-clsid-140615.html.

Para solucionar este problema, los usuarios pueden utilizar uno de los siguientes métodos:

Iniciar con la versión más reciente (8u101) e ignorar la advertencia.
Instalar JRE 8u102 en lugar de JRE 8u101 para evitar este problema.

Para solucionar este problema, los desarrolladores pueden utilizar uno de los siguientes métodos:

Utilizar un ID de clase dinámica en lugar de un ID de clase estática.
Usar java_version si se va a utilizar un applet HTML o un descriptor JNLP si se va a utilizar JNLP.

JDK-8147457 (no público)

Correcciones de bugs

Fecha de caducidad de Java

La fecha de caducidad de 8u101 es el 19 de octubre de 2016. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u101) el 19 de noviembre de 2016. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

» Notas de la versión 8u101

Java 8 Update 91 (8u91)

Características principales de la versión

Datos IANA 2016a
JDK 8u91 contiene datos de zona horaria IANA versión 2016a. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Corrección de bug: corrección de la regresión del tiempo de inicio del applet
JDK-8080977 ha provocado un retraso en el inicio del applet. El retraso solo aparece en IE y dura unos 20 segundos. JDK-8136759 ha eliminado este retraso. Consulte JDK-8136759
Corrección de bug: La generación de firmas DSA ahora está sujeta a la comprobación de nivel de seguridad de clave
Para generar firmas, si el nivel de seguridad del algoritmo de resumen es menor que el de la clave utilizada para firmar la firma (p. ej., utiliza claves DSA de 2048 o 256 bits con la firma SHA1withDSA), se producirá un error en la operación con el siguiente mensaje de error: "El nivel de seguridad del algoritmo de resumen SHA1 no es suficiente para este tamaño de clave". JDK-8138593 (no público)
Corrección de error: Problema de liveconnect con Firefox 42
Debido a que puede producir errores en el explorador, ya no se procesan llamadas de JavaScript a Java si se inicia el plugin de Java desde plugin-container.exe (comportamiento por defecto de Firefox 42) y el estado del applet no es Listo(2). Si el applet no está listo (el estado no es 2), no se ejecuta el método Java real y solo se devuelven valores nulos.

Si el plugin se inicia desde plugin-container.exe, no utilice llamadas JavaScript a Java que puedan necesitar más de 11 segundos (valor por defecto de dom.ipc.plugins.hangUITimeoutSecs) para realizarse o que puedan mostrar un cuadro de diálogo modal durante la llamada JavaScript a Java. En este caso, el thread principal del navegador debe bloquearse, lo que puede causar que el navegador se cuelgue y que el plugin termine.

Solución alternativa para Firefox 42: Los usuarios pueden establecer dom.ipc.plugins.enabled=false. El efecto secundario de esta solución es que cambia la configuración de todos los plugins. JDK-8144079 (no público)
Corrección de bug: El nuevo atributo para los servidores JMX RMI JRMP especifica una lista de nombres de clase que utilizar al anular la serialización de las credenciales de servidor
Se ha definido un nuevo atributo de Java para el entorno para permitir que el servidor JMX RMI JRMP especifique una lista de nombres de clase. Estos nombres se corresponden con el cierre de los nombres de clase esperado por el servidor al anular la serialización de credenciales. Por ejemplo, si las credenciales esperadas eran
```
 List<string>
```
se cerrarían todas las clases concretas que pudieran esperarse de manera serializada en una lista de cadenas.

Por defecto, este atributo lo utiliza únicamente el agente por defecto con los siguientes elementos:
```
 { "[Ljava.lang.String;", "java.lang.String" } 
```
Solo se aceptarán matrices de cadenas y cadenas al anular la serialización de las credenciales. El nombre de atributo es:
```
"jmx.remote.rmi.server.credential.types" 
```
Este es un ejemplo de un usuario que inicia un servidor con los nombres de clase de credenciales especificados:
```
 Map<string, object=""> env = new HashMap<>(1); env.put ( "jmx.remote.rmi.server.credential.types", new String[]{ String[].class.getName(), String.class.getName() } ); JMXConnectorServer server = JMXConnectorServerFactory.newJMXConnectorServer(url, env, mbeanServer); 
```
Se puede utilizar la nueva función directamente especificando:
"jmx.remote.rmi.server.credential.types"

JDK-8144430 (no público)
Corrección de bug: Se ha desactivado el algoritmo de firma MD5withRSA en el proveedor JSSE
El algoritmo de firma MD5withRSA se considera ahora inseguro y ya no se debe utilizar. Como consecuencia, MD5withRSA se ha desactivado por defecto en la implantación de Oracle JSSE agregando "MD5withRSA" a la propiedad de seguridad "jdk.tls.disabledAlgorithms". A partir de ahora, los mensajes de comunicación TLS y los certificados X.509 firmados con el algoritmo MD5withRSA ya no están soportados por defecto. Este cambio amplía la restricción de certificados basada en MD5 ("jdk.certpath.disabledAlgorithms") para incluir también mensajes de comunicación en la versión de TLS 1.2. Si es necesario, se puede volver a activar este algoritmo eliminando "MD5withRSA" de la propiedad de seguridad "jdk.tls.disabledAlgorithms". JDK-8144773 (no público)
Corrección del bug: Se han agregado nuevos certificados a las CA raíz
Se han agregado ocho nuevos certificados raíz:
- Alias QuoVadis Root CA 1 G3 : quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM
- Alias QuoVadis Root CA 2 G3 : quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3
- Alias QuoVadis Root CA 3 G3 : quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM
- Alias DigiCert Assured ID Root G2 : digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- Alias DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- Alias DigiCert Global Root G2 : digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- Alias DigiCert Global Root G3 : digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- Alias DigiCert Trusted Root G4 : digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US
Consulte JDK-8145954 y JDK-8145955.

Notas

Eliminación de JRE estáticos
Los instaladores Java para Windows publicados antes de la versión 8u91 no eliminaban los JRE instalados de forma estática por defecto. Para eliminar los JRE que se hubieran instalado de forma estática, los usuarios tenían que seleccionar manualmente esos JRE en la interfaz de usuario del instalador Java. Ahora, en las versiones de Java 8u91 y posteriores, los JRE que se hubieran instalado de forma estática se eliminarán automáticamente si están por debajo de la línea base de seguridad. Para obtener más información sobre la instalación estática, consulte Configuración de Java Runtime Environment.

Fecha de caducidad de Java

La fecha de caducidad de 8u91 el 19 de julio de 2016. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u91) el 19 de agosto de 2016. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

» Notas de la versión 8u91

Java 8 Update 77 (8u77)

Características principales de la versión

Datos IANA 2016a
JDK 8u77 contiene datos de zona horaria IANA versión 2016a. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.

Fecha de caducidad de Java

8u77 caduca el 19 de abril de 2016. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u77) el 19 de mayo de 2016. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Notas

Esta alerta de seguridad (8u77) se basa en la versión anterior de PSU 8u74. Todos los usuarios de versiones de JDK 8 anteriores deben actualizar a esta versión. Si desea obtener más información sobre las diferencias entre las actualizaciones de parche crítico y la del juego de parches, visite Java CPU and PSU Releases Explained (Explicación de versiones de PSU y Java CPU)

La alerta de seguridad para CVE-2016-0603 no afecta a las demostraciones, ejemplos y paquetes de documentación de 8u77, por lo que las demostraciones, ejemplos y paquetes de documentación seguirán siendo de la versión más reciente hasta el lanzamiento de la actualización del parche crítico de abril.

Correcciones de bugs

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Asesor de actualización de parche crítico de Oracle Java SE.

» Notas de la versión 8u77

Java 8 Update 73 (8u73)

Características principales de la versión

Datos IANA 2015g
JDK 8u71 contiene datos de zona horaria IANA versión 2015g. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.

Fecha de caducidad de Java

8u73 caduca el 19 de abril de 2016. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u73) el 19 de mayo de 2016. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Notas

A los usuarios de Java que hayan descargado las versiones afectadas y tengan previsto instalarlas en el futuro, Oracle les recomienda que descarten las versiones antiguas. Los usuarios de Java que hayan instalado la actualización de parche crítico de enero de 2016 para las versiones de Java SE 6, 7 u 8, no tienen que realizar ninguna acción. Los usuarios de Java que no hayan instalado la actualización de parche crítico de enero de 2016 para las versiones de Java SE 6, 7 u 8, deben actualizar a las versiones de Java SE 6, 7 u 8 de la alerta de seguridad sobre CVE-2016-0603.

La alerta de seguridad para CVE-2016-0603 no afecta a las demostraciones, ejemplos y paquetes de documentación de 8u73, por lo que las demostraciones, ejemplos y paquetes de demostración de la versión 8u71 seguirán siendo de la versión más reciente hasta el lanzamiento de la actualización del parche crítico de abril.

Correcciones de bugs

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Asesor de actualización de parche crítico de Oracle Java SE. Recuerde que 8u73 no contiene las versiones de PSU que sí incluye 8u72. Los clientes que necesiten las correcciones de bugs adicionales que se incluyen en 8u72, deberán actualizar a 8u74 en lugar de a 8u73.

» Notas de la versión 8u73

Java 8 Update 71 (8u71)

Características principales de la versión

Datos IANA 2015g
JDK 8u71 contiene datos de zona horaria IANA versión 2015g. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Corrección del bug: al ejecutar jps como raíz no se muestra toda la información
Después de la corrección de JDK-8050807 (corregido en 8u31, 7u75 y 6u91), al ejecutar jps como raíz no se muestra toda la información de los procesos de Java que han iniciado otros usuarios en otros sistemas. Este error se ha corregido. Consulte JDK-8075773.
Corrección del bug: los Installers aparecen detenidos en la configuraciones de ESC
Es posible que los usuarios que ejecuten Internet Explorer Enhance Security Configuration (ESC) en Windows Server 2008 R2 hayan tenido problemas al instalar Java en el modo interactivo. Este problema se ha resuelto en la versión 8u71. Los Installers ejecutados en el modo interactivo no aparecerán detenidos en las configuraciones de ESC. Consulte JDK-8140197.
Corrección de bug: problema con los algoritmos PBE que utilizan cifrado AES corregido
Se ha corregido un error en los PBE que utilizan cifrados AES de 256 bits que consiste en que la clave derivada puede ser diferente y no equivalente a las claves anteriormente derivadas de la misma contraseña. JDK-8138589 (no público).
Corrección de bug: Límite por defecto agregado para el tamaño máximo de la entidad XML
Se ha limitado por defecto el tamaño máximo de la entidad. Para obtener más información sobre los límites de procesamiento de XML, consulte The Java Tutorials, Processing Limits (Tutoriales Java, Límites de procesamiento). JDK-8133962 (no público)
Corrección de bug:Se ha corregido el problema con la opción 'REMOVEOLDERJRES' en la documentación del conmutador Enterprise MSI
La documentación de Enterprise MSI incluye las opciones de configuración. Faltaba la opción REMOVEOLDERJRES usada para desinstalar los antiguos JRE. Se ha agregado esta opción, con la siguiente descripción:
Si se define en 1, se eliminan las versiones anteriores de JRE que hubiera instaladas en el sistema.
El valor por defecto, 0, no elimina ningún JRE antiguo
JDK-8081237 (no público)

Fecha de caducidad de Java

8u71 caduca el 19 de abril de 2016. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u71) el 19 de mayo de 2016. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Asesor de actualización de parche crítico de Oracle Java SE.

Para acceder a una lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u71.

» Notas de la versión 8u71

Java 8 Update 66 (8u66)

Características principales de la versión

8u66 versión 18 soluciona un problema en Firefox.

Corrección de bug: _releaseObject llamado desde thread incorrecto
Un reciente cambio en Firefox produce que la llamada a _releaseObject se realice desde otro thread en lugar de hacerlo desde el principal. Esto puede causar una condición de carrera que podría producir fallos en el explorador de forma involuntaria. Esto se ha resuelto en la versión 18 de 8u66. Para obtener más información, consulte Bugs@Mozilla 1221448. Consulte JDK-8133523.

El plugin de Java no funciona en Firefox tras instalar Java

Firefox 42 puede bloquearse al intentar ejecutar el plugin de Java. Las soluciones alternativas se indican en la lista de preguntas frecuentes. Consulte JDK-8142908 (no público).

Fecha de caducidad de Java

La fecha de caducidad de 8u66 es el 19 de enero de 2016. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u66) el 19 de febrero de 2016. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Asesor de actualización de parche crítico de Oracle Java SE.

Para acceder a una lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de JDK 8u66.

» Notas de la versión 8u66

Java 8 Update 65 (8u65)

Características principales de la versión

Datos IANA 2015f
JDK 8u60 contiene datos de zona horaria IANA versión 2015f. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Soporte ISO 4217, tabla 'Códigos de fondo actuales' (A.2)
Esta mejora agrega soporte para los código de fondo ISO 4217, tabla A.2. Hasta ahora, el JDK solo soportaba las monedas de la tabla A.1. Consulte JDK-8074350.
Corrección de bug: [mac osx] Fallo del cliente JRE AU instalado al actualizar a NEXTVER en Mac 10.11
Se ha introducido un nuevo installer en la versión 8u65 para actualizar a los usuarios de OS X a la versión más reciente. Installer se aplicará a las actualizaciones programadas y manuales y los paquetes estarán disponibles en java.com y OTN. Los usuarios que tengan problemas de compatibilidad con la nueva versión del instalador podrán descargar e instalar manualmente Installer '.pkg" disponible en My Oracle Support.
Corrección de bug: HotSpot debe utilizar la interfaz PICL para obtener la memoria de línea de caché en SPARC
Ahora es obligatorio utilizar la biblioteca libpicl en Solaris/SPARC para determinar el tamaño de las líneas de caché. En caso de que la biblioteca no esté presente o de que el servicio de PICL no esté disponible, JVM mostrará una advertencia y se desactivarán las optimizaciones del compilador que utilicen la instrucción BIS (almacén de inicio de bloque). Consulte JDK-8056124.
Corrección de bug: dns_lookup_realm debe estar definido en false por defecto
El valor de dns_lookup_realm del archivo krb5.conf de Kerberos es por defecto false. Consulte JDK-8080637.
Corrección del bug: La carga previa de libjsig.dylib provoca el interbloqueo si se llama a signal()
Las aplicaciones deben precargar la biblioteca libjsig para activar la cadena de señales. Hasta ahora en OS X, después de precargar libjsig.dylib, cualquier llamada de código nativo a signal() provocaba el interbloqueo. Este error se ha corregido. Consulte JDK-8072147.
Corrección de error: Mejora en dinámica de grupo
En la implantación de OpenJDK SSL/TLS/DTLS (proveedor de SunJSSE), se utilizan los grupos Diffie-Hellman principales seguros por defecto. Los usuarios pueden personalizar los grupos Diffie-Hellman mediante la propiedad de seguridad, jdk.tls.server.defaultDHEParameters.
Corrección del error: Fallo de VM si la clase se redefine con Instrumentation.redefineClasses
¡JVM podría fallar si se ha redefinido una clase con Instrumentation.redefineClasses(). El bloqueo podría deberse a un error de segmentación en SystemDictionary::resolve_or_null o a un error interno con el mensaje 'no coincide la etiqueta con la tabla de resolución de errores'. Este error se ha corregido. Consulte JDK-8076110.

Notas

Si se ejecuta en OSX 10.11 El Capitan y SIP está activado, puede que algunas variables de entorno para depuración de aplicaciones como DYLD_LIBRARY_PATH se eliminen del entorno si se ejecuta Java desde la línea de comandos o haciendo doble clic en un archivo JAR. Las aplicaciones no se deben basar en estas variables en un entorno de producción. Solo son para depurar durante el desarrollo

MD5 no se debe utilizar para firmas digitales si es necesario aplicar resistencia a la colisión. Para evitar el uso de MD5 como algoritmo de firma digital durante las operaciones de certificación de X.509, MD5 se ha agregado a la propiedad de seguridad jdk.certpath.disabledAlgorithms. Para aquellas aplicaciones que aún utilicen el certificado firmado de MD5, actualice el certificado en cuanto le sea posible.

Problemas conocidos

[macosx] Problemas de acceso a pantalla de ofertas de patrocinador (a11y)
Los usuarios que utilicen el teclado para acceder a las interfaces de usuario del Installer de Java, no podrán acceder a los hiperenlaces ni casillas de control de las pantallas de ofertas (anuncios) de software. Como solución alternativa a cómo definir las preferencias relacionadas con el software de publicidad en la interfaz de usuario, los usuarios pueden desactivar dichas ofertas desactivándolas en el panel de control de Java o transfiriendo SPONSORS=0 a través de la línea de comandos. Si desea obtener más información, consulte el apartado de preguntas frecuentes acerca de la instalación de Java sin ofertas de patrocinador. Consulte JDK-8061886 (no público).

Fecha de caducidad de Java

La fecha de caducidad de 8u65 es el 19 de enero de 2016. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u65) el 19 de febrero de 2016. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Asesor de actualización de parche crítico de Oracle Java SE.

Para acceder a una lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u65.

» Notas de la versión 8u65

Java 8 Update 60 (8u60)

Características principales de la versión

Datos IANA 2015e
JDK 8u60 contiene datos de zona horaria IANA versión 2015e. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Corrección de bug: dns_lookup_realm debe estar definido en false por defecto
El valor de dns_lookup_realm del archivo Kerberos' krb5.conf es por defecto false. Consulte 8080637.
Corrección de bug: Desactivación de los conjuntos de cifrado RC4
Los conjuntos de cifrado TLS basados en RC4 (por ejemplo, TLS_RSA_WITH_RC4_128_SHA) ya no son seguros, por lo que no deben seguir usándose (consulte RFC 7465). Como consecuencia, los conjuntos de cifrado TLS basados en RC4 se han desactivado por defecto en la implantación de Oracle JSSE agregando "RC4" a la propiedad de seguridad "jdk.tls.disabledAlgorithms" y eliminándolos de la lista de conjuntos de cifrado activados por defecto. Estos conjuntos de cifrado pueden reactivarse eliminando "RC4" de la propiedad de seguridad "jdk.tls.disabledAlgorithms" en el archivo java.security o llamando de forma dinámica a Security.setProperty() y también volviendo a agregarlos a la lista de conjuntos de cifrado activados con los métodos SSLSocket/SSLEngine.setEnabledCipherSuites(). También puede utilizar la opción de línea de comando -Djava.security.properties para sobrescribir la propiedad de seguridad jdk.tls.disabledAlgorithms. Por ejemplo:
java -Djava.security.properties=my.java.security ...
Donde my.java.security es un archivo que contiene la propiedad sin RC4:
jdk.tls.disabledAlgorithms=SSLv3
Incluso con esta opción definida desde la línea de comandos, deben volver a agregarse los conjuntos de cifrado basados en RC4 a la lista de conjuntos de cifrado activados mediante los métodos SSLSocket/SSLEngine.setEnabledCipherSuites(). Consulte 8076221.
Corrección de bug: Soporte de la detección de tipo de almacén de claves para almacenes de claves JKS y PKCS12
Modo de compatibilidad de almacén de claves: Para mejorar la interoperabilidad, el tipo de almacén de claves de Java JKS ahora soporta el modo de compatibilidad de almacén de claves por defecto. Este modo permite a los almacenes de claves de JKS acceder a los formatos de archivo JKS y PKCS12. Para desactivar el modo de compatibilidad de almacén de claves, defina la propiedad de seguridad keystore.type.compat en el valor de cadena false. Consulte 8062552.
Corrección de bug: Métodos de supervisión Unsafe anticuados en la versión JDK 8u
Los métodos monitorEnter, monitorExit y tryMonitorEnter en sun.misc.Unsafe se han marcado como en desuso en JDK 8u60 y se eliminarán en una futura versión. Estos métodos no se utilizan en el JDK en sí y rara vez se usan fuera del JDK. Consulte 8069302.
Corrección de bug: Extracción de la grabación de JFR del archivo principal mediante SA
DumpJFR es una herramienta basada en el agente de capacidad de servicio que puede usarse para extraer datos de Java Flight Recorder (JFR) de los archivos de núcleo y los procesos de Hotspot activos. Se puede usar DumpJFR mediante uno de los métodos siguientes:
- Asociar DumpJFR a un proceso activo:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883097
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
- Asociar DumpJFR a un archivo de núcleo:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883117
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
La herramienta DumpJFR vuelca los datos de JFR en un archivo denominado recording.jfr en la carpeta de trabajo actual. Consulte 8065301 (no público).
Corrección de bug: Las variables locales denominadas 'enum' provocan fallos falsos del compilador
El analizador javac analiza de forma incorrecta variables locales con el nombre 'enum'; esto provoca fallos falsos cuando un programa con dichas variables locales se compila con un indicador 'source' que corresponde a una versión en la que la construcción enum no está disponible (como '-source 1.4'). Consulte 8069181.

Java Development Kit para ARM versión 8u60

Esta versión incluye Java Development Kit para ARM versión 8u60 (JDK 8u60 para ARM). Para obtener información de soporte de dispositivos ARM, consulte la página Descargas de JDK para ARM. Para obtener una lista de los requisitos del sistema, instrucciones de instalación y consejos de resolución de problemas, consulte la página Instrucciones de instalación.

Limitación: El soporte de Native Memory Tracking está limitado en JDK para ARM. La opción de línea de comando de Java XX:NativeMemoryTracking=detail no está soportada para destinos de ARM (se muestra un mensaje de error al usuario). En su lugar utilice la siguiente opción:
XX:NativeMemoryTracking=summary

Actualizaciones en la documentación por las mejoras de Nashorn

JDK 8u60 incluye nuevas mejoras de Nashorn. Como consecuencia, deben leerse los siguientes cambios en la documentación junto con la documentación de Nashorn existente:

Adición: En la sección anterior mencionamos que todos los objetos JavaScript expuestos a API Java implantan la interfaz java.util.Map. Esto se aplica también a las matrices de JavaScript. Sin embargo, a menudo este no es el comportamiento que se espera o desea cuando el código Java espera objetos analizados por JSON. Las bibliotecas de Java que manipulan objetos analizados por JSON normalmente esperan matrices para exponer en su lugar la interfaz java.util.List. Si necesita exponer sus objetos de JavaScript para exponer las matrices como listas y no como mapas, puede utilizar la función Java.asJSONCompatible(obj), donde obj es la raíz del árbol de objetos de JSON.
Corrección: La precaución mencionada al final de la sección Asignación de tipos de datos ya no es aplicable. Nashorn garantiza que las cadenas de JavaScript internas se convierten a java.lang.String al exponerse de forma externa.
Corrección: La afirmación de la sección Asignación de tipos de datos que menciona "Por ejemplo, las matrices deben convertirse de forma explícita..." no es correcta. Las matrices se convierten de forma automática a tipos de matriz Java, como java.util.List, java.util.Collection, java.util.Queue, java.util.Deque, etc.

Cambios en el juego de reglas de despliegue v1.2

JDK 8u60 implanta el juego de reglas de despliegue (DRS) 1.2, que incluye los siguientes cambios:

Agregue el elemento "checksum" como subelemento de "id", lo que permite que los jar no firmados sean identificados por el total de control SHA-256 del formato sin comprimir de un jar:
- El elemento "checksum" se hará coincidir solo con jar no firmados, y el hash proporcionado se comparará solo con el formato no comprimido del jar.
- El elemento "checksum" (similar al elemento "certificate") tiene dos argumentos "hash" y "algorithm"; sin embargo, a diferencia de lo que ocurre con el elemento "certificate" el único valor soportado para "algorithm" es "SHA-256". Se ignorará cualquier otro valor proporcionado.
Permite que el elemento "message" se aplique a todos los tipos de regla, donde antes solo se aplicaba a una regla de bloque:
- En una regla de ejecución, un subelemento de mensaje hará que se muestre un cuadro de diálogo de mensaje mientras que, sin una regla de ejecución, el comportamiento por defecto sería mostrar un cuadro de diálogo de certificado o formato no firmado. El mensaje se mostrará en el cuadro de diálogo de mensaje.
- En una regla por defecto, el mensaje solo se mostrará si la acción por defecto es el bloqueo. En ese caso, el mensaje se incluirá en el cuadro de diálogo de bloque.
Repita los bloques "customer" en la consola de Java, los archivos de rastreo y los registros de Java Usage Tracker.
- Antes de la versión DRS 1.2, los elementos "customer" podían incluirse (con cualquier subelemento) en el archivo ruleset.xml. Tanto este elemento como todos sus subelementos se ignoran. En DRS 1.2, los elementos siguen ignorándose desde el punto de vista funcional. Aunque:
  - Al analizar el archivo ruleset.xml, todos los bloques "customer" se repetirán en la consola de Java y el archivo de rastreo de despliegue (si la consola y el rastreo están activados).
  - Al utilizar una regla, todos los registros "customer" incluidos en dicha regla se agregarán al registro de Java Usage Tracker (JUT) (si JUT está activado).

Como consecuencia de los cambios expuestos anteriormente, el DTD de DRS 1.2 es el siguiente:
The embedded asset does not exist:
Asset Type: jWidget_C
Asset Id: 1385352043373
PAGENAME: JCOM/jWidget_C/Raw_HTML/Display

Fecha de caducidad de Java

La fecha de caducidad de 8u60 es el 20 de octubre de 2015. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u60) el 20 de noviembre de 2015. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Para acceder a una lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u60.

» Notas de la versión 8u60

Java 8 Update 51 (8u51)

Características principales de la versión

IANA Data 2015d
JDK 8u51 contiene datos de zona horaria de IANA, versión 2015d. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Corrección de bug: Adición de nuevos certificados raíz de Comodo a las CA raíz
Se han agregado cuatro certificados raíz nuevos para Comodo:
1. COMODO ECC Certification Authority alias: comodoeccca DN: CN=COMODO ECC Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
2. COMODO RSA Certification Authority alias: comodorsaca DN: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
3. USERTrust ECC Certification Authority alias: usertrusteccca DN: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
4. USERTrust RSA Certification Authority alias: usertrustrsaca DN: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
Consulte JDK-8077997 (no público).
Corrección de bug: Adición de nuevos certificados raíz de GlobalSign a las CA raíz
Se han agregado dos certificados raíz nuevos para GlobalSign:
1. GlobalSign ECC Root CA - R4 alias: globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
2. GlobalSign ECC Root CA - R5 alias: globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5
Consulte JDK-8077995 (no público).
Corrección de bug: Adición de Actalis a CA raíz
Se ha agregado un nuevo certificado raíz:
Actalis Authentication Root CA alias: actalisauthenticationrootca DN: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT
Consulte JDK-8077903 (no público).
Corrección de bug: Adición de nueva raíz de Entrust ECC
Se ha agregado un nuevo certificado raíz:
Entrust Root Certification Authority - EC1 alias: entrustrootcaec1 DN: CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
Consulte JDK-8073286 (no público).
Corrección de bug: Eliminación de los certificados raíz antiguos de Valicert Class 1 and 2 Policy
Se han eliminado dos certificados raíz con claves de 1024 bits:
1. ValiCert Class 1 Policy Validation Authority alias: secomvalicertclass1ca DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
2. ValiCert Class 2 Policy Validation Authority alias: valicertclass2ca DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Consulte JDK-8077886 (no público).
Corrección de bug: Eliminación de los certificados raíz antiguos de Thawte
Se han eliminado dos certificados raíz con claves de 1024 bits:
1. Thawte Server CA alias: thawteserverca DN: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
2. Thawte Personal Freemail CA alias: thawtepersonalfreemailca DN: EMAILADDRESS=personal-freemail@thawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
Consulte JDK-8074423 (no público).
Corrección de bug: Eliminación de más certificados raíz antiguos de Verisign, Equifax y Thawte
Se han eliminado cinco certificados raíz con claves de 1024 bits:
1. Verisign Class 3 Public Primary Certification Authority - G2 alias: verisignclass3g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
2. Thawte Premium Server CA alias: thawtepremiumserverca DN: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
3. Equifax Secure Certificate Authority alias: equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
4. Equifax Secure eBusiness CA-1 alias: equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
5. Equifax Secure Global eBusiness CA-1, alias: equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
Consulte JDK-8076202 (no público).
Corrección de bug: Eliminación en cacerts de los certificados raíz de la CA TrustCenter
Se han eliminado tres certificados raíz:
1. TC TrustCenter Universal CA I alias: trustcenteruniversalcai DN: CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, O=TC TrustCenter GmbH, C=DE
2. TC TrustCenter Class 2 CA II alias: trustcenterclass2caii DN: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE
3. TC TrustCenter Class 4 CA II alias: trustcenterclass4caii DN: CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, O=TC TrustCenter GmbH, C=DE
Consulte JDK-8072958 (no público).
Corrección de bug: RC4 obsoleto en proveedor SunJSSE
Ahora RC4 se considera un cifrado débil. Los servidores no deben seleccionar RC4 a menos que no haya otro cliente más fuerte en las suites de cifrado solicitadas. Se ha agregado una nueva propiedad de seguridad, jdk.tls.legacyAlgorithms, para definir los algoritmos antiguos en la implantación de Oracle JSSE. Se han agregado los algoritmos relacionados con RC4 a la lista de algoritmos antiguos. Consulte JDK-8074006 (no público).
Corrección de bug: Prohibición de conjuntos de cifrado RC4
RC4 es ahora un cifrado no seguro. Se han eliminado las suites de cifrado RC4 de las listas de suites de cifrado activadas por defecto en el cliente y del servidor para la implantación de Oracle JSSE. Estas suites de cifrado aún se pueden activar con los métodos SSLEngine.setEnabledCipherSuites() y SSLSocket.setEnabledCipherSuites(). Consulte JDK-8077109 (no público).
Corrección de bug: Mejora de la comprobación de certificación
Con esta corrección, la identificación de puntos finales de JSSE no realiza la consulta de nombre inversa para las direcciones IP por defecto en JDK. Si una aplicación necesita realizar consulta de nombre inversa para las direcciones IP raíz en las conexiones SSL/TLS y encuentra un problema de compatibilidad de identificación de punto final, se puede utilizar la propiedad del sistema "jdk.tls.trustNameService" en la consulta de nombre inversa. Tenga en cuenta que si el servicio de nombres no es de confianza, al activar la consulta de nombre inversa se pueden producir ataques de MITM. Consulte JDK-8067695 (no público).

Fecha de caducidad de Java

La fecha de caducidad de 8u51 es el 20 de octubre de 2015. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u51) el 20 de noviembre de 2015. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Asesor de actualización de parche crítico de Oracle Java SE.

Para acceder a una lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u51.

» Notas de la versión 8u51

Java 8 Update 45 (8u45)

Características principales de la versión

Datos IANA 2015a
JDK 8u45 contiene datos de zona horaria de IANA, versión 2015a. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Corrección de bug: Mejora del manejo de archivos jar. A partir de la versión JDK 8u45, la herramienta jar ya no permite la barra inicial "/" y ".." (punto-punto) como componente de ruta de acceso en el nombre de archivo de entrada zip al crear nuevos elementos y/o extraer de archivos jar y zip. Si es necesario, la nueva opción de línea de comandos "-P" debe utilizarse de forma explícita para conservar el punto-punto y/o el componente de ruta de acceso absoluta. Consulte 8064601 (no público).
Corrección de bug: La aplicación JNLP con la sección "resource" anidada falla con NPE en la carga en jre8u40. Una aplicación JNLP, con etiquetas anidadas dentro de una etiqueta <java> o puede devolver una NPE. Ya se ha solucionado el problema. La etiqueta solo debe usarse si se utiliza realmente <java>. Consulte 8072631 (no público).

Fecha de caducidad de Java

La fecha de caducidad para 8u45 es el 14 de julio de 2015. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u45) el 14 de agosto de 2015. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Asesor de actualización de parche crítico de Oracle Java SE.

Para acceder a una lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u45.

» Notas de la versión 8u45

Java 8 Update 40 (8u40)

Características principales de la versión

Datos IANA 2014j
JDK 8u40 contiene datos de zona horaria de IANA, versión 2014j. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Corrección de errores: métodos de interfaz estática y por defecto en JDI, JDWP y JDB. A partir de JDK 8 es posible contar con métodos estáticos y por defecto que se pueden ejecutar directamente en las interfaces. Estos métodos no son ejecutables mediante JDWP o JDI y, por tanto, no pueden depurarse correctamente. Consulte JDK 8 Compatibility Guide (Guía de compatibilidad con JDK 8) para obtener más información. Consulte 8042123.
Corrección de bug: Java Access Bridge se puede activar desde el panel de control para JRE de 32 bits. Previamente, la casilla de control "Activar Java Access Bridge" se eliminó del panel de control de Java con los JRE de 64 bits desinstalados, incluso cuando había JRE de 32 bits presentes en el sistema. A partir de la versión JDK 8u40, se conserva la casilla de control "Activar Java Access Bridge" si hay un JRE de 32 bits presente. Puede encontrarla en Panel de control -> Accesibilidad -> Centro de accesibilidad -> Usar la computadora sin pantalla. Por tanto, un usuario puede activar Java Access Bridge a través del panel de control para consultar 8030124.
Corrección de bug: modernización de la pila de medios de JavaFX en Mac OS X. Se agrega una plataforma de reproductor basada en AVFoundation a los medios de JavaFX. La antigua plataforma basada en QTKit ya se puede eliminar de la compatibilidad de la App Store de Mac. Consulte 8043697 (no público)
Corrección de bug: faltan API de DOM. En la versión JDK 8u40, las API de DOM del plugin antiguo se eliminaron involuntariamente. Si un applet requiere el uso de com.sun.java.browser.dom.DOMService para comunicarse con el explorador, es posible que los usuarios necesiten actualizar el applet para utilizar netscape.javascript.JSObject o continuar utilizando JDK 8 Update 31. Este problema se ha solucionado en la versión 26 y se han publicado installers 8u40 nuevos. Si tiene este problema, descargue los installers JDK 8u40 actualizados y ejecútelos. Consulte 8074564.
Corrección de bug: Mac 10.10: La aplicación que se ejecuta con pantalla de presentación tiene problemas de enfoque. Las aplicaciones que se han iniciado a través de webstart o de aplicaciones autónomas y utilizan la pantalla de presentación no tienen enfoque de teclado. Solución alternativa: inicie javaws con la opción -Xnosplash. Este problema se ha solucionado en la versión 27 y se ha publicado un installer 8u40 nuevo. Si tiene este problema, descargue el Installer JDK 8u40 actualizado y ejecútelo. Consulte 8074668.
Mejoras en la herramienta Java Packager
La versión JDK 8u40 contiene las siguientes mejoras de Java Packager:
- Los argumentos de línea de comandos se pueden transferir a aplicaciones independientes. Los argumentos por defecto se definen cuando se crea el paquete y los puede sustituir el usuario al iniciar la aplicación.
- Las asociaciones de archivos se pueden configurar cuando una aplicación independiente se instala de forma que el sistema operativo ejecuta automáticamente la aplicación para extensiones de archivos registradas o tipos de MIME.
- La API UserJvmOptionsService está disponible para modificar las opciones de JVM en aplicaciones independientes. La nueva configuración se utilizará la próxima vez que se inicie la aplicación.
- Se admiten varios puntos de entrada para aplicaciones independientes, lo que permite agrupar un conjunto de productos en el mismo paquete de aplicación.
API en desuso
El mecanismo de sustitución de estándares aprobados y el mecanismo de extensión están en desuso y puede que se eliminen en futuras versiones. No hay cambios del tiempo de ejecución. Recomendamos que las aplicaciones existentes que utilizan los mecanismos de "sustitución de estándares aprobados" o de "extensión" los dejen de usar. Para ayudar a identificar el uso de estos mecanismos, está disponible la opción de línea de comandos -XX:+CheckEndorsedAndExtDirs. Fallará si alguna de las siguientes condiciones es verdadera:
- Las propiedades del sistema -Djava.endorsed.dirs o -Djava.ext.dirs están definidas para modificar la ubicación por defecto; o
- El directorio ${java.home}/lib/endorsed existe; o
- ${java.home}/lib/ext contiene algún archivo JAR que excluye los que envía JDK; o
- Cualquier directorio de extensión del sistema completo específico de la plataforma contiene archivos JAR.
La opción de línea de comandos -XX:+CheckEndorsedAndExtDirs se admite en JDK 8u40 y versiones posteriores.
Diferencias entre las páginas de la herramienta JJS
La versión en japonés de la página de ayuda de JJS es diferente de la versión en inglés. Algunas de las opciones no admitidas se han eliminado de la versión en inglés de la página de la herramienta JJS. La versión en japonés del documento se actualizará en el futuro. Consulte 8062100 (no público). Si quiere conocer otros cambios en la página de la herramienta JJS, consulte Mejora de las herramientas en JDK 8.
Cambio en los valores por defecto de G1HeapWastePercent y G1MixedGCLiveThresholdPercent
El valor por defecto de G1HeapWastePercent ha cambiado de 10 a 5 para reducir la necesidad de GC completos. Por el mismo motivo, el valor por defecto de G1MixedGCLiveThresholdPercent ha cambiado de 65 a 85.
Nueva interfaz de filtrado de acceso de clase de Java
La interfaz jdk.nashorn.api.scripting.ClassFilter permite restringir el acceso a clases de Java específicas por parte de scripts ejecutados por un motor de scripts Nashorn. Consulte Restricción del acceso de scripts a clases específicas de Java en la guía del usuario de Nashorn, así como 8043717 (no público) si desea obtener más información.
Problemas con los proveedores de terceros de JCE
Gracias a la corrección de JDK-8023069 (en JDK 8u20), se actualizaron los proveedores SunJSSE y SunJCE, así como algunas interfaces internas. Algunos proveedores de terceros de JCE (como RSA JSAFE) utilizan algunas interfaces sun.* internal y, por tanto, no funcionarán con el proveedor SunJSSE actualizado. Dichos proveedores deberán actualizarse para poder funcionar con el proveedor SunJSSE actualizado. Si se ha visto afectado por este problema, póngase en contacto con el proveedor de JCE para conseguir una actualización. Consulte 8058731.
Reactivación de cifrado en Solaris Crypto Framework
Si utiliza Solaris 10, le interesará saber que hemos realizado un cambio para reactivar las operaciones con MD5, SHA1 y SHA2 mediante Solaris Crypto Framework. Si le aparece un error CloneNotSupportedException o el mensaje de error de PKCS11 CKR_SAVED_STATE_INVALID en JDK 8u40, debería verificar que tiene los siguientes parches y, en caso de no tenerlos, aplicar los más recientes:
- 150531-02 en sparc
- 150636-01 en x86
Actualizaciones de la guía de solución de problemas de NMT
Native Memory Tracking (NMT) es una función de VM de Java Hotspot que realiza un seguimiento del uso de la memoria interna de una JVM de HotSpot. Native Memory Tracking se puede utilizar para supervisar las asignaciones de memoria interna de VM y diagnosticar las faltas de memoria de VM. La página de mejoras de VM se actualiza con las funciones de NMT. Consulte Mejoras de Java Virtual Machine en Java SE 8. La guía de solución de problemas está actualizada con las funciones de NMT. Consulte Native Memory Tracking.
La función Iniciador de varios JRE está en desuso
La función de selección de versión de JRE durante el inicio o la función Iniciador de varios JRE está en desuso en JDK 8u40. Las aplicaciones que requieren el despliegue de versiones de Java específicas mediante esta función deberán optar por otras soluciones de despliegue, como Java WebStart.
Mejoras de JavaFX
A partir de la versión JDK 8u40, se han mejorado los controles de JavaFX para soportar las tecnologías de asistencia, lo que significa que ya es posible acceder a los controles de JavaFX. Asimismo, se proporciona una API pública para permitir que los desarrolladores escriban sus propios controles accesibles. Se proporciona soporte de accesibilidad en plataformas Windows y Mac OS X, en el que se incluye:
- Soporte para leer controles de JavaFX mediante un lector de pantalla
- Los controles de JavaFX se pueden hacer transversales mediante el teclado
- Soporte para un modo de alto contraste especial que incrementa la visibilidad de los controles para los usuarios.
Consulte 8043344 (no público).

En la versión JDK 8u40 se incluyen nuevos controles de IU de JavaFX: un control de número, soporte de texto con formato y un juego estándar de cuadros de diálogo de alerta.
- Control de selector cíclico: un selector cíclico es un campo de texto de una sola línea que permite al usuario seleccionar un número o un valor de objeto de una secuencia ordenada. Consulte la clase javafx.scene.control.Spinner si desea obtener más información.
- Texto con formato: una nueva clase de TextFormatter proporciona la capacidad de formatear el texto en las subclases de TextInputControl (por ejemplo, TextField y TextArea). Consulte la clase javafx.scene.control.TextFormatter si desea obtener más información.
- Recuadros de diálogo: la clase Dialog permite que las aplicaciones creen sus recuadros de diálogo propios y personalizados. Asimismo, al proporcionarse una clase Alert, se amplía Dialog y se ofrece soporte para una serie de tipos de recuadro de diálogo integrados que se pueden mostrar a los usuarios para solicitar una respuesta. Consulte las clases javafx.scene.control.Dialog, javafx.scene.control.Alert, javafx.scene.control.TextInputDialog y javafx.scene.control.ChoiceDialog si desea obtener más información.
Consulte 8043350 (no público).

Funciones comerciales

Uso compartido de datos de clase de aplicación (AppCDS)
El uso compartido de datos de clase de aplicación (AppCDS) amplía las capacidades de CDS para que pueda colocar las clases de los directorios de extensiones estándar y la ruta de acceso de la clase de aplicación en el archivo compartido. Esta es una función experimental y no dispone de licencia de uso comercial. Consulte la opción -XX:+UseAppCDS en la página de la herramienta del iniciador de Java.
Gestión de memoria cooperativa
A partir de la versión JDK 8u40, se ha agregado la noción de "presión de memoria" a JDK. La presión de memoria es una propiedad que representa el uso de memoria total (RAM) en el sistema. Cuanto mayor sea dicha presión, más probable es que se agote la memoria del sistema. Esta es una función experimental y no dispone de licencia de uso comercial. En caso de que aumente de la presión de memoria, el JDK reacciona intentando reducir el uso de memoria. Esto se consigue reduciendo el tamaño de la pila de Java, principalmente. Las acciones que el JDK llevará a cabo para reducir el uso de memoria pueden provocar que el rendimiento se resienta. Esta es una elección intencional. La aplicación proporciona el nivel de presión a través de una JMX MXBean. Para ello utiliza una escala de 0 (sin presión) a 10 (memoria a punto de agotarse). Para activar esta función, se debe registrar jdk.management.cmm.SystemResourcePressureMXBean. La presión de memoria se define mediante el atributo "MemoryPressure".
También está disponible un nuevo indicador de línea de comandos, -XX:MemoryRestriction, que lleva uno de los argumentos 'none', 'low', 'medium' o 'high'. Este indicador definirá la presión inicial en el JDK y también funcionará cuando la MXBean no esté registrada. La gestión de memoria cooperativa requiere G1 GC (-XX:+UseG1GC). Esta función no es compatible con el indicador -XX:+ExplicitGCInvokesConcurrent.
Nuevos indicadores comerciales
Ahora hay dos nuevas opciones de VM para los titulares de licencias comerciales:
- -XX:+ResourceManagement
- -XX:ResourceManagementSampleInterval=value (milisegundos)
Si quiere obtener más documentación, consulte la documentación del iniciador Java.
Nueva documentación del instalador de MSI:
Ya está disponible la Guía del instalador de Microsoft Windows Installer (MSI) Enterprise JRE. El instalador MSI Enterprise JRE requiere una licencia comercial para su uso en producción. Más información sobre las funciones comerciales y cómo activarlas.

Fecha de caducidad de Java

8u40 caduca el 14 de abril de 2015. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u40) el 14 de mayo de 2015. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Para acceder a la lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u40.

» Notas de la versión 8u40

Java 8 Update 31 (8u31)

Características principales de la versión

Datos IANA 2014j
JDK 8u31 contiene datos de zona horaria de IANA, versión 2014j. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
SSLv3 está desactivado por defecto
A partir de la versión JDK 8u31, el protocolo SSLv3 (Secure Socket Layer) se ha desactivado y no suele estar disponible. Consulte la propiedad jdk.tls.disabledAlgorithms en el archivo \lib\security\java.security. Si Sslv3 es absolutamente necesario, se puede volver a activar el protocolo eliminando 'SSLv3' de la propiedad jdk.tls.disabledAlgorithms en el archivo java.security o definiendo dinámicamente esta propiedad de seguridad antes de inicializar JSSE.
Cambios en el panel de control de Java
A partir de la versión JDK 8u31, se elimina el protocolo SSLv3 de las opciones avanzadas del panel de control de Java. Si el usuario necesita utilizar SSLv3 para aplicaciones, puede volver a activarlo manualmente de la siguiente manera:
- Activar protocolo SSLv3 en nivel JRE: según se describe en la sección anterior.
- Activar protocolo SSLv3 en el nivel de despliegue: edite el archivo deployment.properties y agregue lo siguiente:
  
  deployment.security.SSLv3=true

Fecha de caducidad de Java

8u31 caduca el 14 de abril de 2015. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u31) el 14 de mayo de 2015. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Asesor de actualización de parche crítico de Oracle Java SE.

Para acceder a una lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u31.

» Notas de la versión 8u31

Java 8 Update 25 (8u25)

Características principales de la versión

Datos IANA 2014c
JDK 8u25 contiene datos de zona horaria de IANA, versión 2014c. Para obtener más información, consulte Versiones de datos de zona horaria en el software de JRE.
Corrección de bug: Disminución del modo de preferencia de RC4 en la lista de conjuntos de cifrado activada
Esta corrección disminuye la preferencia de conjuntos de cifrado basados en RC4 en la lista de conjuntos de cifrado del proveedor SunJSSE activada por defecto. Consulte 8043200 (no público).
Corrección de bug: JRE 8u20 se bloquea al utilizar IM japonés en Windows
La VM se bloquea cuando se utilizan los controles de swing al introducir algunos caracteres chinos o japoneses en la plataforma Windows. Ya se ha solucionado el problema. Consulte 8058858 (no público).

Instrucciones para desactivar SSL v3.0 en Oracle JDK y JRE

Oracle recomienda que los usuarios y desarrolladores desactiven el uso del protocolo SSLv3.
» ¿Cómo pueden los usuarios de Java confirmar que no están afectados por la vulnerabilidad 'Poodle' de SSL v3.0?

Fecha de caducidad de Java

La fecha de caducidad de 8u25 es el 20 de enero de 2015. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u25) el 20 de febrero de 2015. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Asesor de actualización de parche crítico de Oracle Java SE.

Para acceder a la lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u25.

» Notas de la versión 8u25

Java 8 Update 20 (8u20)

Características principales de la versión

Se han agregado nuevos indicadores a la API de gestión de Java
Los indicadores MinHeapFreeRatio y MaxHeapFreeRatio ahora se pueden gestionar. Es decir, se pueden cambiar en tiempo de ejecución con la API de gestión en Java. También se ha agregado soporte para estos marcadores en ParallelGC como parte de la política de tamaño adaptativo.
Cambios en el instalador de Java
- Disponible un nuevo installer para Microsoft Windows Installer (MSI) Enterprise JRE que permite al usuario instalar JRE en toda la empresa. Consulte la sección Descarga de Installer en Instalación de JRE para Microsoft Windows para para obtener más información. El Installer de MSI Enterprise JRE solo está disponible como parte de Java SE Advanced o Java SE Suite. Para obtener información sobre estos productos comerciales, consulte Java SE Advanced y Java SE Suite.
- La herramienta de desinstalación de Java está integrada con el installer para contar con una opción para eliminar las versiones anteriores de Java del sistema. El cambio se aplica a plataformas Windows de 32 bits y 64 bits. Consulte Desinstalación de JRE.
Cambios en el panel de control de Java
- El separador Actualizar del panel de control de Java permite a los usuarios actualizar automáticamente los JRE de 64 bits (además de las versiones de 32 bits) que haya instalados en su sistema.
- El nivel de seguridad Media se ha eliminado. Ahora solo están disponibles los niveles Alta y Muy alta. Los applets que no cumplen con las prácticas de seguridad más recientes todavía se pueden ejecutar si los sitios que los albergan están incluidos en la lista de excepciones de sitios. La lista de excepciones de sitios proporciona a los usuarios la opción de permitir los mismos applets que se habrían permitido si se hubiera seleccionado la opción Media, pero sitio por sitio, reduciendo así al mínimo el riesgo de utilizar configuraciones más permisivas.
Compilador Java actualizado
El compilador javac se ha actualizado para implantar el análisis de asignaciones definitivas para el acceso a campos finales en blanco mediante "this". Consulte JDK 8 Compatibility Guide (Guía de compatibilidad con JDK 8) para obtener más información.
Cambio en la versión de Java mínima necesaria para el plugin Java y Java Webstart
La versión mínima de Java necesaria para el plugin de Java y Java Webstart es ahora Java 5. Los applets que no se ejecuten en Java 5 o posterior se deben pasar a una versión posterior de Java para seguir funcionando. Los applets escritos para versiones anteriores pero que se puedan ejecutar al menos en Java 5 continuarán funcionando.
Cambio en el formato de salida de UsageTracker
El formato de salida de UsageTracker ha pasado a utilizar comillas para evitar la confusión en el log. Esto puede implicar cambios en la forma en que dicha información se lee. La función se puede configurar para que se comporte como en versiones anteriores, aunque se recomienda el nuevo formato. Consulte la documentación sobre el sistema de seguimiento de uso de Java.
Cambios en las herramientas de empaquetado de Java
- javafxpackager ahora se denomina javapackager
- La opción"-B" se ha agregado al comando de implantación de javapackager para permitir la transferencia de argumentos a los paquetes que se utilizan para crear aplicaciones independientes. Consulte la documentación sobre javapackager (Windows)/(Unix) para obtener más información
- El argumento del parámetro de ayuda se ha agregado a la Referencia de la tarea Ant de JavaFX. Permite especificar el argumento (en el elemento ) para el grupo que se utiliza para crear aplicaciones independientes.

Fecha de caducidad de Java

La fecha de caducidad de 8u20 es el 14 de octubre de 2014. Java caduca cada vez que hay disponible una nueva versión con correcciones a las vulnerabilidades de seguridad. Para los sistemas que no se pueden ejecutar en servidores Oracle, un mecanismo secundario se encargará de caducar esta versión de JRE (versión 8u20) el 14 de noviembre de 2014. Una vez se haya cumplido cualquiera de las condiciones (la nueva versión esté disponible o se haya alcanzado la fecha de caducidad) Java enviará mensajes de advertencia y recordatorios sobre la nueva versión.

Correcciones de bugs

Para acceder a una lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u20.

» Notas de la versión 8u20

Java 8 Update 11 (8u11)

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Aviso de actualización de parche crítico de Oracle.

Para acceder a una lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u11.

» Notas de la versión 8u11

Java 8 Update 5 (8u5)

Esta versión incluye correcciones para vulnerabilidades de seguridad. Para obtener más información, consulte el Aviso de actualización de parche crítico de Oracle.

Para acceder a una lista de las correcciones de bugs que incluye esta versión, consulte la página Correcciones de bugs de JDK 8u5.

» Notas de la versión 8u5

Java versión 8

» Notas técnicas sobre la versión de JDK y JRE 8