Saltar al contenido

Notas de la versión del JDK 13, cambios importantes e información

octubre 3, 2021

Introducción

Estas notas describen cambios importantes, mejoras, API y funciones eliminadas, API y funciones obsoletas y otra información sobre JDK 13 y Java SE 13. En algunos casos, las descripciones proporcionan enlaces a información detallada adicional sobre un problema o un cambio. Esta página no duplica las descripciones proporcionadas por el Java SE 13 (JSR 388) Especificación de plataforma, que proporciona antecedentes informativos para todos los cambios de especificación y también puede incluir la identificación de API eliminadas o obsoletas y características que no se describen aquí. La especificación Java SE 13 (JSR 388) proporciona enlaces a:

Debe conocer el contenido de ese documento, así como los elementos descritos en esta página.

Las descripciones de esta página de notas de la versión también identifican posibles problemas de compatibilidad que puede encontrar al migrar a JDK 13. El Tipos de compatibilidad La página en la wiki de OpenJDK identifica tres tipos de posibles problemas de compatibilidad para los programas Java utilizados en estas descripciones:

  • Fuente: La compatibilidad de fuentes conserva la capacidad de compilar el código fuente existente sin errores.
  • Binario: La compatibilidad binaria se define en La especificación del lenguaje Java como preservar la capacidad de vincular archivos de clases existentes sin errores.
  • Comportamiento: La compatibilidad de comportamiento incluye la semántica del código que se ejecuta en tiempo de ejecución.

Ver CSR aprobados para JDK 13 para la lista de CSR cerrados en JDK 13 y el Revisión de compatibilidad y especificaciones (CSR) en la wiki de OpenJDK para obtener información general sobre compatibilidad.

Datos IANA 2019b

JDK 13 contiene la versión 2019b de datos de zona horaria de IANA. Para obtener más información, consulte Versiones de datos de zona horaria en el software JRE.

Novedades de JDK 13: nuevas funciones y mejoras

Esta sección describe algunas de las mejoras en Java SE 13 y JDK 13. En algunos casos, las descripciones proporcionan enlaces a información adicional detallada sobre un problema o un cambio. Las API que se describen aquí son las que se proporcionan con oracleJDK. Incluye una implementación completa de la plataforma Java SE 13 y API de Java adicionales para respaldar el desarrollo, la depuración y la supervisión de aplicaciones Java. Otra fuente de información sobre mejoras importantes y nuevas funciones en Java SE 13 y JDK 13 es el Java SE 13 (JSR 388) Platform Specification, que documenta los cambios realizados en la especificación entre Java SE 12 y Java SE 13. Este documento incluye descripciones de las nuevas funciones y mejoras que también son cambios en la especificación. Las descripciones también identifican posibles problemas de compatibilidad que puede encontrar al migrar a JDK 13.

core-libs/java.nio

Se agregó el método FileSystems.newFileSystem (Path, Map )

Se han agregado tres nuevos métodos a java.nio.file.FileSystems para facilitar el uso de proveedores de sistemas de archivos que tratan el contenido de un archivo como un sistema de archivos.

  • newFileSystem(Path)
  • newFileSystem(Path, Map<String, ?>)
  • newFileSystem(Path, Map<String, ?>, ClassLoader)

La suma de newFileSystem(Path, Map<String, ?>) crea un problema de compatibilidad de origen (pero no binario) para el código que ha estado usando el 2-arg existente newFileSystem(Path, ClassLoader) y especificando el cargador de clases como null. Por ejemplo, lo siguiente no se puede compilar porque la referencia a newFileSystem es ambiguo:

FileSystem fs = FileSystems.newFileSystem(path, null);

Para evitar la referencia ambigua, este código debe modificarse para convertir el segundo parámetro a java.lang.ClassLoader.

JDK-8218875

core-libs/java.nio

Nuevos métodos java.nio.ByteBuffer Bulk get / put Transfer Bytes sin tener en cuenta la posición del búfer

java.nio.ByteBuffer y los otros tipos de búfer en java.nio ahora defina volumen absoluto get y put métodos para transferir secuencias contiguas de bytes sin tener en cuenta o afectar la posición del búfer.

JDK-5029431

core-libs/java.time

Nuevo nombre de la era japonesa Reiwa

Se ha agregado a esta actualización una instancia que representa la nueva era Reiwa. A diferencia de otras épocas, no existe un campo público para esta era. Se puede obtener llamando JapaneseEra.of(3) o JapaneseEra.valueOf("Reiwa"). JDK 13 y posteriores tendrán un nuevo campo público para representar esta era.

El nombre del marcador de posición, «NewEra«, para la era japonesa que comenzó a partir del 1 de mayo de 2019, se ha reemplazado por el nuevo nombre oficial. Las aplicaciones que se basaban en el nombre del marcador de posición (consulte JDK-8202088) para obtener el singleton de la nueva era (JapaneseEra.valueOf("NewEra")) ya no funcionará.

JDK-8205432

core-libs/java.util:i18n

Soporte para Unicode 12.1

Esta versión actualiza la compatibilidad con Unicode a 12.1, que incluye lo siguiente:

  • java.lang.Character admite la base de datos de caracteres Unicode de nivel 12.1, en la que 12.0 agrega 554 caracteres desde 11.0, para un total de 137,928 caracteres. Estas adiciones incluyen 4 nuevos scripts, para un total de 150 scripts, así como 61 nuevos caracteres emoji. 12.1 agrega exactamente un carácter, U+32FF SQUARE ERA NAME REIWA, desde 12.0.
  • java.text.Bidi y java.text.Normalizer Las clases admiten el nivel 12.0 de los Anexos estándar Unicode, # 9 y # 15, respectivamente.
  • java.util.regex El paquete admite clústeres de Grapheme extendidos basados ​​en el nivel 12.0 del anexo estándar n. ° 29 de Unicode

JDK-8221431

hotspot/gc

JEP 351 ZGC Anular memoria no utilizada

ZGC se mejoró para devolver la memoria del montón no utilizada al sistema operativo. Esto es útil para aplicaciones y entornos donde la huella de memoria es una preocupación.

Esta función está habilitada de forma predeterminada, pero se puede deshabilitar explícitamente usando -XX:-ZUncommit. Además, la memoria no se eliminará de modo que el tamaño del montón se reduzca por debajo del tamaño mínimo del montón (-Xms). Esto significa que esta función se deshabilitará implícitamente si el tamaño de pila mínimo (-Xms) está configurado para ser igual al tamaño máximo de pila (-Xmx).

Se puede configurar un retraso de no compromiso usando -XX:ZUncommitDelay=<seconds> (predeterminado en 300 segundos). Este retraso especifica cuánto tiempo debería haber estado sin utilizar la memoria antes de que sea elegible para la cancelación.

Para obtener más detalles, consulte (JEP 351).

JDK-8220347

hotspot/gc

Se agregó el indicador -XXSoftMaxHeapSize

La bandera de línea de comandos manejable -XX:SoftMaxHeapSize=<bytes> ha sido añadido. Actualmente, solo tiene efecto cuando el recolector de basura Z está habilitado (-XX:+UseZGC).

Cuando se establece, el GC se esforzará por no hacer crecer el montón más allá del tamaño especificado, a menos que el GC decida que es necesario hacerlo para evitar OutOfMemoryError. No se permite establecer el tamaño máximo de almacenamiento dinámico en un valor mayor que el tamaño máximo de almacenamiento dinámico (-Xmx). Cuando no se establece en la línea de comando, tiene un valor predeterminado igual al tamaño máximo de almacenamiento dinámico.

Ser manageable, su valor se puede ajustar en tiempo de ejecución. Por ejemplo, su valor se puede ajustar usando jcmd VM.set_flag SoftMaxHeapSize <bytes> oa través del HotSpot MXBean.

Establecer esta bandera puede ser útil en varias situaciones, como:

  • En entornos donde el uso de recursos es una preocupación, es posible que desee mantener baja la huella del montón y, al mismo tiempo, conservar la capacidad para hacer frente a un aumento temporal en los requisitos de espacio de montón.
  • Al usar un GC concurrente (como ZGC), es posible que desee ir a lo seguro y aumentar el nivel de confianza de que no se encontrará con un bloqueo de asignación debido a un aumento imprevisto en la tasa de asignación. Establecer un tamaño de pila máximo suave anima al GC a mantener un montón más pequeño, lo que significa que el GC recolectará basura de manera más agresiva de lo que lo haría de otra manera, haciéndolo más resistente a un aumento repentino en la tasa de asignación de aplicaciones.

JDK-8222145

hotspot/gc

Tamaño máximo de pila de ZGC aumentado a 16 TB

El tamaño de pila máximo admitido para ZGC se aumentó de 4 TB a 16 TB.

JDK-8221786

hotspot/runtime

Archivado de CDS dinámicos JEP 350

JEP 350 extiende el intercambio de datos de clases de aplicaciones (AppCDS) para permitir el archivo dinámico de clases cuando una aplicación Java está saliendo. También mejora la usabilidad de AppCDS al eliminar la necesidad de que los usuarios realicen pruebas para crear una lista de clases para cada aplicación. El archivo estático existente habilitado por el -Xshare:dump La opción, usando una lista de clases, continúa funcionando como está.

El archivo generado dinámicamente se crea sobre el archivo del sistema predeterminado empaquetado con la imagen JDK en ejecución. Se genera un archivo de almacenamiento de capa superior para cada aplicación. El usuario puede especificar el nombre de archivo del nombre del archivo dinámico como argumento de la -XX:ArchiveClassesAtExit opción. Por ejemplo, el siguiente comando crea hello.jsa:

% bin/java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello

Para ejecutar la misma aplicación usando este archivo dinámico:

% bin/java -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello

El usuario también puede especificar los archivos base y dinámicos en el -XX:SharedArchiveFile opción como:

-XX:SharedArchiveFile=<base archive>:<dynamic archive>

RSE JDK-8221706 tiene más detalles sobre la opción de línea de comando.

JDK-8207812

security-libs/java.security

Tiempo de espera de lectura configurable para CRL

los com.sun.security.crl.readtimeout La propiedad del sistema establece el tiempo de espera máximo de lectura para las recuperaciones de CRL, en segundos. Si la propiedad no se ha establecido, o si su valor es negativo, se establece en el valor predeterminado de 15 segundos. Un valor de 0 significa un tiempo de espera infinito.

JDK-8191808

security-libs/java.security

Nuevo comando keytool -showinfo -tls para mostrar información de configuración TLS

Un nuevo keytool -showinfo -tls Se ha agregado un comando que muestra la información de configuración de TLS.

JDK-8219861

security-libs/javax.crypto

Soporte para MS Cryptography Next Generation (CNG)

El proveedor SunMSCAPI ahora admite la lectura de claves privadas en formato Cryptography Next Generation (CNG). Esto significa que las claves RSA y EC en formato CNG se pueden cargar desde los almacenes de claves de Windows, como «Windows-MY». Algoritmos de firma relacionados con EC (SHA1withECDSA, SHA256withECDSA, etc.) también son compatibles.

JDK-8026953

security-libs/javax.crypto:pkcs11

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, firmas DSA que usan la familia SHA-2 de resúmenes de mensajes y firmas RSASSA-PSS cuando los mecanismos PKCS11 correspondientes son compatibles con la biblioteca PKCS11 subyacente.

JDK-8080462

security-libs/javax.net.ssl

Soporte para X25519 y X448 en TLS

Los grupos de curvas elípticas nombrados x25519 y x448 ahora están disponibles para el acuerdo de claves JSSE en TLS versiones 1.0 a 1.3, con x25519 siendo el más preferido de los grupos con nombre habilitados por defecto. La lista ordenada predeterminada es ahora:


x25519, secp256r1, secp384r1, secp521r1, x448,
 sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1,
 secp256k1,
 ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192

La lista predeterminada se puede anular utilizando la propiedad del sistema

close