RESEÑA FUNCIONALIDADES NUEVAS ULTIMA VERSIÓN DE JAVA

Comencemos por definir que es java: Java es un lenguaje de programación y una

plataforma informática comercializada por primera vez en 1995 por Sun
Microsystems. Hay muchas aplicaciones y sitios web que no funcionarán a menos
que tenga Java instalado y cada día se crean más. Java es rápido, seguro y fiable.
Desde portátiles hasta centros de datos, desde consolas para juegos hasta súper
computadoras, desde teléfonos móviles hasta Internet, Java está en todas
partes.¿La descarga de Java es gratuita? Sí, la descarga de Java es gratuita. Puede
obtener la última versión en java.com.

¿Por qué debería actualizarme a la versión más reciente de Java? Ya que La

versión más reciente de Java contiene importantes mejoras para el rendimiento,
estabilidad y seguridad de las aplicaciones Java que se ejecutan en su equipo.

Algunas de las nuevas mejoras que trae la versión de JDK 13 son:

core-libs / java.nio

Se agregó el método FileSystems.newFileSystem (Path, Map <String,?>)

Se han agregado tres métodos nuevos java.nio.file.FileSystemspara 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 adición de newFileSystem(Path, Map<String, ?>)crea un problema de

compatibilidad de origen (pero no binario) para el código que ha estado utilizando el
2-arg existente newFileSystem(Path, ClassLoader)y especificando el cargador de
clases como null.Por ejemplo, no se puede compilar lo siguiente porque la
referencia a newFileSystemes ambigua:

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

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

Ver JDK-8218875

core-libs / java.nio

Nuevos java.nio.ByteBuffer Bulk get / put Métodos Bytes de transferencia sin

importar la posición del buffer

java.nio.ByteBuffery los otros tipos de búfer java.nioahora definen el volumen

absoluto gety los putmétodos para transferir secuencias contiguas de bytes sin tener
en cuenta o afectar la posición del búfer.

Ver JDK-5029431

core-libs / java.time

Nuevo nombre de la era japonesa Reiwa

Se ha agregado una instancia que representa la nueva era Reiwa a esta
actualización. A diferencia de otras épocas, no hay campo público para esta era. Se
puede obtener llamando a 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ó
el 1 de mayo de 2019, ha sido reemplazado por el nuevo nombre oficial. Las
aplicaciones que se basaban en el nombre del marcador de posición para obtener
la nueva era singleton ( JapaneseEra.valueOf("NewEra")) ya no funcionarán.

Ver JDK-8205432

core-libs / java.util: i18n

Soporte para Unicode 12.1

Esta versión actualiza el soporte Unicode a 12.1 que incluye lo siguiente:

 java.lang.Characteradmite la base de datos de caracteres Unicode de nivel

12.1, en el que 12.0 agrega 554 caracteres desde 11.0, para un total de
137,928 caracteres. Estas adiciones incluyen 4 nuevos guiones, para un total
de 150 guiones, así como 61 nuevos caracteres emoji. 12.1 agrega
exactamente un carácter U+32FF SQUARE ERA NAME REIWA, desde 12.0.
 java.text.Bidiy las java.text.Normalizerclases admiten el nivel 12.0 de Anexos
estándar Unicode, # 9 y # 15, respectivamente.
 java.util.regex el paquete admite clústeres de grafemas extendidos basados
en el nivel 12.0 del anexo estándar estándar 29 de Unicode.

Ver JDK-8221431

punto de acceso / gc

JEP 351 ZGC no comprometer memoria no utilizada

ZGC se mejoró para devolver la memoria de almacenamiento dinámico no utilizada

al sistema operativo. Esto es útil para aplicaciones y entornos donde la huella de la
memoria es una preocupación.

Esta característica está habilitada de manera predeterminada, pero puede

deshabilitarse explícitamente usando -XX:-ZUncommit. Además, la memoria no se
comprometerá, de modo que el tamaño de almacenamiento dinámico se reducirá
por debajo del tamaño mínimo de almacenamiento dinámico ( -Xms). Esto significa
que esta característica se deshabilitará implícitamente si el tamaño mínimo de
almacenamiento dinámico ( -Xms) está configurado para ser igual al tamaño
máximo de almacenamiento dinámico ( -Xmx).

Se puede configurar un retraso no confirmado utilizando -

XX:ZUncommitDelay=<seconds>(el valor predeterminado es 300 segundos). Este
retraso especifica durante cuánto tiempo la memoria debería haber estado sin usar
antes de que sea elegible para no confirmar.

Ver JDK-8220347

punto de acceso / gc

Agregado -XXSoftMaxHeapSize Flag

Se -XX:SoftMaxHeapSize=<bytes>ha agregado el indicador de línea de comandos

manejable . 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. El tamaño máximo dinámico de almacenamiento
dinámico no puede establecerse 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,
el valor predeterminado es igual al tamaño de almacenamiento dinámico máximo.

Siendo manageable, su valor se puede ajustar en tiempo de ejecución. Por ejemplo,

su valor se puede ajustar mediante jcmd VM.set_flag SoftMaxHeapSize <bytes>o
mediante HotSpot MXBean.

Establecer este indicador puede ser útil en una serie de situaciones, como:

 En entornos donde el uso de recursos es una preocupación, es posible que

desee mantener baja la huella del almacenamiento dinámico y al mismo
tiempo conservar la capacidad de lidiar con un aumento temporal en el
requisito de espacio de almacenamiento dinámico.
 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 puesto de
asignación debido a un aumento imprevisto en la tasa de
asignación. Establecer un tamaño de almacenamiento dinámico máximo
suave alienta al GC a mantener un almacenamiento dinámico más pequeño,
lo que significa que el GC recolectará la basura de forma más agresiva de lo
que lo haría de otro modo, lo que lo hace más resistente a un aumento
repentino en la tasa de asignación de aplicaciones.
Ver JDK-8222145

punto de acceso / gc

El tamaño máximo de almacenamiento dinámico de ZGC aumentó a 16 TB

El tamaño máximo de almacenamiento dinámico compatible con ZGC se incrementó

de 4 TB a 16 TB.

Ver JDK-8221786

punto de acceso / tiempo de ejecución

Archivo de CDS dinámico JEP 350

JEP 350 amplía el uso compartido de datos de clase de aplicación ( AppCDS ) para
permitir el archivado 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 ejecuciones de prueba para crear una lista de clases para cada
aplicación. El archivo estático existente habilitado por la -Xshare:dumpopción,
usando una lista de clase, continúa funcionando como está.

El archivo generado dinámicamente se crea sobre el archivo predeterminado del

sistema empaquetado con la imagen JDK en ejecución. Se genera un archivo de
archivo de capa superior por separado para cada aplicación. El usuario puede
especificar el nombre de archivo del nombre de archivo dinámico como argumento
para la -XX:ArchiveClassesAtExitopció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 podría especificar tanto los archivos base como los dinámicos en
la -XX:SharedArchiveFileopción, tales como:

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

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

Ver JDK-8207812

security-libs / java.security

Tiempo de espera de lectura configurable para CRL

La com.sun.security.crl.readtimeoutpropiedad del sistema establece el tiempo de

espera de lectura máximo 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.

Ver JDK-8191808

security-libs / java.security

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

configuración de TLS

Se keytool -showinfo -tlsha agregado un nuevo comando que muestra información

de configuración de TLS.

Ver 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 CE
( SHA1withECDSA, SHA256withECDSAtambién están soportados, etc.).

Ver JDK-8026953

security-libs / javax.crypto: pkcs11

Proveedor SunPKCS11 actualizado con soporte para PKCS # 11 v2.40

El proveedor SunPKCS11 ha sido 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 cuando los mecanismos PKCS11
correspondientes son compatibles con la biblioteca PKCS11 subyacente.

Ver JDK-8080462

security-libs / javax.net.ssl

Soporte para X25519 y X448 en TLS

Los grupos de curvas elípticas con nombre x25519y x448ahora están disponibles
para el acuerdo de clave JSSE en las versiones de TLS 1.0 a 1.3, x25519siendo 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 jdk.tls.namedGroups.

Ver JDK-8171279

security-libs / javax.net.ssl

Reanudación de sesión sin estado del lado del servidor en JSSE

La característica permite que el lado del servidor de JSSE funcione sin

estado. Como se describe en RFC 5077 1 para TLS 1.2 y siguientes, y RFC
8446 2 para TLS 1.3, el servidor TLS envía información de sesión interna en forma
de un ticket de sesión cifrado a un cliente que admite apátridas. Ese ticket de sesión
se presenta al servidor durante el protocolo de enlace TLS para reanudar la
sesión. Esto debería mejorar el rendimiento y el uso de memoria del servidor TLS en
grandes cargas de trabajo, ya que la caché de sesión rara vez se utilizará. Con
menos información de sesión almacenada en caché, es posible que parte de la
información de sesión no esté disponible. Esta función no está habilitada de manera
predeterminada y se puede activar configurando dos propiedades.

Tenga en cuenta que las sesiones TLS sin estado invalidadas podrían reanudarse
en la implementación actual. No se garantiza que el comportamiento sea el mismo
en futuras versiones y actualizaciones.

Tenga en cuenta que en la implementación actual, el valor de retorno

de SSLSession.getID()no es persistente durante la reanudación de TLS 1.3 y las
conexiones sin estado TLS 1.2. Esto podría ser un problema si las aplicaciones se
basan en los valores del identificador de sesión. Esto puede cambiar para ser
consistente en una versión futura .

Se agregan dos nuevas propiedades del sistema en apoyo de esta

característica: jdk.tls.client.enableSessionTicketExtensionse usa en el lado del
cliente para alternar la extensión del ticket de sesión en el mensaje de saludo del
cliente para TLS 1.2. Valor de la propiedad: " true" envía la extensión, " false" no
(predeterminado).

jdk.tls.server.enableSessionTicketExtensionpermite que un servidor use tickets de

sesión sin estado si el cliente lo admite. Los clientes que no admiten tickets de
sesión sin estado utilizarán la memoria caché. Valor de la propiedad: " true" habilita
sin estado " false" no (predeterminado).

Ver JDK-8211018
security-libs / javax.security

Permitir la restricción de los mecanismos SASL

Se jdk.sasl.disabledMechanismsha agregado una propiedad de seguridad

llamada que se puede usar para deshabilitar los mecanismos SASL. Cualquier
mecanismo deshabilitado se ignorará si se especifica en el mechanismsargumento
de Sasl.createSaslCliento el mechanismargumento de Sasl.createSaslServer. El
valor predeterminado para esta propiedad de seguridad está vacío, lo que significa
que no se deshabilitan los mecanismos listos para usar.

Ver JDK-8200400

security-libs / javax.xml.crypto

Nuevas constantes de cadena para URI Canonical XML 1.1

Nuevas constantes de cadena

nombradas INCLUSIVE_11y INCLUSIVE_11_WITH_COMMENTSagregadas a
la javax.xml.crypto.dsig.CanonicalizationMethodAPI. Estos representan los URI para
Canonical XML 1.1 y Canonical XML 1.1 con algoritmos de Comentarios para XML
Signature.

Ver JDK-8224767

security-libs / javax.xml.crypto

[xmldsig] Agregado KeyValueEC_TYPE

El ECKeyValuetipo descrito en la Recomendación W3C para XML-Signature

Sintaxis y Procesamiento es ahora compatible. Se EC_TYPEha agregado una
nueva constante a la javax.xml.crypto.dsig.keyinfo.KeyValueinterfaz. Tenga en
cuenta que NamedCurveactualmente solo se admite el tipo de parámetro de
dominio, y ECParametersno se admite el tipo de parámetro de curva explícita.

Ver JDK-8223053

security-libs / org.ietf.jgss

Se agregó una biblioteca GSS-API nativa predeterminada en Windows

Se ha agregado una biblioteca nativa GSS-API a JDK en la plataforma Windows. La
biblioteca es solo del lado del cliente y utiliza las credenciales predeterminadas. Se
cargará cuando la sun.security.jgss.nativepropiedad del sistema se establezca en
"verdadero". Un usuario aún puede cargar una biblioteca GSS-API nativa de
terceros configurando la propiedad del sistema sun.security.jgss.liben su ruta.

Ver JDK-6722928

security-libs / org.ietf.jgss: krb5

Soporte para referencias cruzadas de Kerberos (RFC 6806)

El cliente Kerberos se ha mejorado con el soporte de canonicalización de nombres

principales y referencias entre reinos, según lo definido por la extensión de protocolo
RFC 6806.

Como resultado de esta nueva característica, el cliente Kerberos puede aprovechar

configuraciones de entorno más dinámicas y no necesariamente necesita saber (de
antemano) cómo llegar al reino de un principal objetivo (usuario o servicio).

El soporte está habilitado de forma predeterminada y 5 es el número máximo de

saltos de referencia permitidos. Para desactivarlo, establezca
la sun.security.krb5.disableReferralspropiedad de seguridad o del sistema en
falso. Para configurar un número máximo personalizado de saltos de referencia,
establezca la sun.security.krb5.maxReferralspropiedad de seguridad o del sistema
en cualquier valor positivo.

Ver JDK-8215032

herramientas / javac

Expresiones de conmutador JEP 354 (vista previa)

Extienda switchpara que pueda usarse como una declaración o una expresión, y
para que ambas formas puedan usar case ... :etiquetas tradicionales (con caída) o
nuevas case ... ->etiquetas (sin caída), con una nueva declaración adicional para
obtener un valor de un switchexpresión. Estos cambios simplificar la codificación
todos los días, y preparar el camino para el uso de la coincidencia de
patrones en switch. Esta es una función de idioma de vista previa en JDK 13

herramientas / javac

Bloques de texto JEP 355 (Vista previa)

Agregue bloques de texto al lenguaje Java. Un bloque de texto es un literal de

cadena de varias líneas que evita la necesidad de la mayoría de las secuencias de
escape, formatea automáticamente la cadena de forma predecible y le da al
desarrollador control sobre el formato cuando lo desee. Esta es una función de
idioma de vista previa en JDK 13.

xml / jaxp

Nuevos métodos para crear fábricas DOM y SAX con soporte de espacio de
nombres

Se han agregado nuevos métodos para crear instancias de fábricas DOM y SAX con
soporte de espacio de nombres de forma predeterminada. Estos métodos tienen el
prefijo sobre sus contrapartes existentes con "NS", que significa
NamespaceAware. A continuación se muestra una lista de los nuevos métodos:

 newDefaultNSInstance()
 newNSInstance()
 newNSInstance(String factoryClassName, ClassLoader classLoader)

Usando estos nuevos métodos, un analizador creado a través de la fábrica será

NamespaceAware por defecto. Por ejemplo, la siguiente declaración:

DocumentBuilder db =
DocumentBuilderFactory.newDefaultNSInstance().newDocumentBuilder();

es equivalente a:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newDefaultInstance();

dbf.setNamespaceAware(true);
DocumentBuilder db = dbf.newDocumentBuilder();

Ver JDK-8219692