Clases ocultas, clases selladas, bloques de texto , registros y EdDSA: JDK 15 tiene mucho valor.
Como dice una de mis expresiones favoritas, Java 15 contiene muchas bondades de chocolate rico. La nueva versión (lanzada el 15 de septiembre de 2020) incluye 14 cambios importantes (JEP) destinados a mejorar el JDK. Este artículo proporciona una descripción general rápida de nuevos productos basada en la información contenida en el JEP.
Los 14 JEP se pueden dividir en cinco grupos. Para un estudio más detallado, consulte la documentación de cada uno de ellos.
Nueva funcionalidad que te dejará sin aliento:
- JEP 339: Algoritmo de firma digital de curva de Edwards (EdDSA)
- JEP 371: Clases ocultas
Adiciones a la funcionalidad estándar de Java SE existente:
- JEP 378: bloques de texto
- JEP 377: recolector de basura ZGC
- JEP 379: Shenandoah - Recolector de basura de pausa baja
Mejoras en la funcionalidad heredada de Java SE:
- JEP 373: Revisión de la API de DatagramSocket obsoleta
Esperamos nuevos productos:
- JEP 360: clases selladas (versión preliminar)
- JEP 375: Coincidencia de patrones, por ejemplo, de (Segunda vista previa)
- JEP 384: Entradas (segundo borrador)
- JEP 383: API de acceso a memoria externa (función de segunda incubadora)
Eliminación y terminación del soporte:
- JEP 372: Nashorn JavaScript Engine
- JEP 374:
- JEP 381: Solaris SPARC
- JEP 385: RMI
,
Algoritmo de firma digital Edwards Curve ( JEP 339 ). Seré el primero en admitir que el algoritmo de firma digital Edwards-Curve (EdDSA) está un poco más allá de mis conocimientos de cifrado. De acuerdo, no sé nada en absoluto. Sin embargo, este JEP está diseñado como una implementación independiente de la plataforma de EdDSA con un mejor rendimiento que la implementación de C existente, ECDSA.
Según la documentación de JDK, EdDSA es un esquema de firma de curva elíptica moderno que tiene varias ventajas sobre los existentes en el JDK.
Objetivos de implementación:
- El objetivo principal de este JEP es implementar el esquema de firmas estandarizado en RFC 8032 . Sin embargo, el nuevo esquema no reemplaza a ECDSA.
- - EdDSA , ECDSA . , EdDSA, Curve25519 ~126 , , ECDSA, secp256r1 ~128 .
- , . .
Ahora sabes más que yo. Esté atento a un artículo de la revista Java que explicará EdDSA pronto.
Las clases ocultas ( JEP 371 ) son clases que no pueden ser invocadas directamente por el código de bytes de otras clases. Están destinados a ser utilizados por marcos que crean clases dinámicamente en tiempo de ejecución y las usan indirectamente a través de un mecanismo de reflexión. Es posible que las clases generadas dinámicamente solo sean necesarias durante un período de tiempo limitado, por lo que mantenerlas durante la vida útil de una clase generada estáticamente puede aumentar innecesariamente la huella de memoria.
Las clases generadas dinámicamente también son indetectables. Encontrar tales clases por nombre sería perjudicial, ya que socava su propósito, que es que son solo un detalle de implementación de una clase generada estáticamente.
El lanzamiento de las clases ocultas sienta las bases para que los desarrolladores dejen de usar la API no estándar sun.misc.Unsafe :: defineAnonymousClass . Oracle tiene la intención de eliminar y eliminar esta clase en el futuro.
Adiciones a los estándares Java SE existentes
Los bloques de texto ( JEP 378 ) que vinieron del Proyecto Amber finalmente se lanzaron después de dos versiones preliminares en JDK 13 y 14. El propósito de su creación fue el deseo de los desarrolladores de reducir la dificultad de declarar y usar cadenas literales de múltiples líneas en Java.
Los bloques de texto dan formato automáticamente a las cadenas de una manera predecible, pero si eso no es suficiente, el desarrollador puede hacerse cargo del formato. La segunda versión de la funcionalidad preliminar introduce dos nuevas secuencias de escape para manejar nuevas líneas y espacios. Por ejemplo, \ <line-terminator> suprime explícitamente la inserción de un carácter de nueva línea.
Anteriormente, para imprimir una línea larga de texto, tendría que escribir así:
El uso de \ facilita la lectura del código:
La secuencia de escape \ s puede evitar que se eliminen los espacios finales. Así, el siguiente texto representa tres líneas, cada una de las cuales consta exactamente de cinco caracteres (en la línea media, correspondiente al verde, no se utiliza \ s, porque ya contiene cinco caracteres).
El recolector de basura ZGC ( JEP 377 ) se introdujo en JDK 11 como una función experimental. Ahora ha recibido estatus oficial. ZGC es un recolector de basura escalable, compatible con NUMA y paralelo con baja latencia de recolección de basura (menos de 10 milisegundos incluso en montones de varios terabytes). El tiempo de pausa promedio, según lo probado por Oracle, es menos de 1 milisegundo y el máximo es menos de 2 milisegundos. La Figura 1 compara el recolector de basura paralelo de Java, G1 y ZGC, con el tiempo de pausa de ZGC aumentado en un factor de 10.
Figura 1. Comparación de los tiempos de pausa del recolector de basura
Sin embargo, para muchas cargas de trabajo, G1 (que sigue siendo el predeterminado) puede ser un poco más rápido que ZGC. Además, para montones muy pequeños, como los de unos pocos cientos de megabytes, el G1 también puede ser más rápido. Por lo tanto, se le recomienda que ejecute sus propias pruebas con sus propias cargas para ver qué recolector de basura usar.
Importante: dado que ZGC ya no es experimental (incluido en la compilación de Oracle OpenJDK y en Oracle JDK), ya no necesita usar -XX: + UnlockExperimentalVMOptions para activarlo.
Shenandoah ( JEP 379) Es otra variante del recolector de basura disponible en algunas compilaciones de OpenJDK. Ha sido experimental desde JDK 12. Ahora, como con ZGC, XX: + UnlockExperimentalVMOptions no es necesario.
Modernización de la funcionalidad heredada de Java SE
Reelaboración de la API DatagramSocket obsoleta ( JEP 373 ). Considere esto básicamente como una refactorización de un código jurásico, ya que este JEP reemplaza las implementaciones antiguas y difíciles de mantener de las API java.net.DatagramSocket y java.net.MulticastSocket con implementaciones modernas más simples que son fáciles de mantener y depurar, y que trabajar con flujos virtuales de Project Loom.
Dado que hay una gran cantidad de código que usa la API anterior (desde JDK 1.0), la implementación obsoleta no se eliminará. De hecho, una nueva propiedad del sistema específica de JDK, jdk.net.usePlainDatagramSocketImpl, configura el JDK para usar una implementación obsoleta si la refactorización de API causa problemas con las pruebas de regresión o en algunos casos.
Esperamos nuevos productos
Clases selladas ( JEP 360 ). La primera versión de preproducción creada en Project Amber. Las clases e interfaces selladas restringen su extensión o implementación a otras clases. ¿Por qué es importante? Un desarrollador puede querer administrar el código responsable de implementar una clase o interfaz en particular. Las clases selladas proporcionan una forma más declarativa que los modificadores de acceso para restringir el uso de la superclase. Por ejemplo:
El propósito de sellar una clase es que el código del cliente sepa qué subclases están permitidas. Después de todo, puede haber casos de uso en los que se espera que la definición original de una clase (o interfaz) sea completamente exhaustiva, y cuando el desarrollador no permite que se extienda fuera de control, solo las clases especificadas explícitamente pueden hacerlo.
Existen algunas restricciones para las clases selladas:
- La clase sellada y sus subclases permitidas deben estar en el mismo módulo. Si se declaran en un módulo sin nombre, deben colocarse en el mismo paquete
- Cada subclase permitida debe extender directamente la clase sellada
- , , , — final, sealed nonsealed ( )
Coincidencia de patrones, por ejemplo, de ( JEP 375 ). La segunda vista previa es otro desarrollo de Project Amber. La primera versión preliminar de la funcionalidad estaba en Java 14 y no hay cambios en comparación con eso.
El objetivo es mejorar Java mediante la coincidencia de patrones para el operador instanceof. Esto le permite expresar de manera más concisa y segura la lógica general del programa, es decir, la extracción condicional de componentes de objetos. Permítanme referirlos al excelente artículo de Mal Gupta " Coincidencia de patrones, por ejemplo, en Java 14 " como ejemplo.
Entradas ( JEP 384), segundo borrador. Los registros son clases que actúan como portadores transparentes de datos inmutables. El nuevo JEP incluye aclaraciones basadas en los comentarios de la comunidad y admite varias formas adicionales de clases e interfaces locales. Las entradas también provienen del Proyecto Amber.
Los registros son una construcción orientada a objetos que expresa una simple agregación de valores. Por tanto, ayudan a los programadores a centrarse en modelar datos inmutables en lugar de comportamientos extensibles. Los registros implementan automáticamente métodos basados en datos como iguales y descriptores de acceso. Las entradas también conservan principios de Java de larga data, como la escritura nominal y la compatibilidad de migración. En otras palabras, facilitan la codificación y la lectura de clases que contienen datos inmutables.
External Memory Access ( JEP 383 ) es la segunda versión de incubadora de la API que permite a los programas Java acceder de forma segura y eficiente a la memoria externa fuera del montón de Java. El objetivo es comenzar a reemplazar java.nio.ByteBuffer y sun.misc.Unsafe. Es parte del proyecto de Panamá que mejora la comunicación entre Java y otras API.
El JEP describe acertadamente la necesidad de esta innovación de la siguiente manera:
cuando se trata de acceder a la memoria externa, los desarrolladores se enfrentan a un dilema: ¿deberían elegir una ruta segura, pero limitada (y posiblemente menos eficiente), como la API ByteBuffer, o deberían ¿Renunciar a las garantías de seguridad y adoptar una API insegura peligrosa y no compatible?
Este JEP presenta una API segura, fácil de mantener y eficiente para acceder a la memoria externa. Al proporcionar una solución específica al problema del acceso a la memoria externa, los desarrolladores se librarán de las limitaciones y peligros de las API existentes. También obtendrán un mejor rendimiento ya que la nueva API está diseñada desde cero con optimizaciones JIT en mente.
Retiro y fin del soporte
Ninguna de estas decisiones debería ser controvertida.
Eliminación del motor JavaScript Nashorn ( JEP 372 ). Este motor, su API y la herramienta jjs quedaron obsoletas en Java 11. Es hora de decir adiós.
Deshabilitar y eliminar el bloqueo reservado ( JEP 374 ) elimina la antigua técnica de optimización utilizada por HotSpot JVM para reducir la sobrecarga asociada con el bloqueo no verificado. Históricamente, este bloqueo ha dado lugar a importantes mejoras de rendimiento con respecto a los métodos de bloqueo convencionales, pero las mejoras de rendimiento observadas en el pasado son mucho menos obvias hoy. El costo de ejecutar instrucciones atómicas en procesadores modernos se ha reducido.
El bloqueo redundante ha dado lugar a una gran cantidad de código complejo, y esta complejidad impide que el equipo de desarrollo de Java realice cambios significativos en el motor de sincronización. Al deshabilitar el bloqueo y dejar que el programador lo vuelva a habilitar, el equipo de desarrollo de Java espera determinar si sería prudente eliminarlo por completo en una versión futura.
Eliminación de puertos Solaris y SPARC ( JEP 381 ). En este caso, se elimina todo el código fuente específico del sistema operativo Solaris y la arquitectura SPARC. No hay nada más que decir.
Excluya la activación de RMI para una desinstalación posterior ( JEP 385). Simplifica Java al eliminar la parte obsoleta de llamar a métodos remotos que era opcional en Java 8.
El uso de la activación de RMI se reduce y reduce. El equipo de Java no ve evidencia de que se hayan escrito nuevas aplicaciones con él, y hay evidencia de que muy pocas aplicaciones existentes usan la activación RMI. La búsqueda en varias bases de código de fuente abierta no encontró casi ninguna mención de ninguna API asociada. No ha habido informes de errores de activación de RMI generados externamente durante varios años.
Dar soporte a la activación de RMI como parte de la plataforma Java tiene un costo de mantenimiento continuo. Esto agrega complejidad a RMI. Puede eliminar la activación de RMI sin afectar al resto de RMI. Eliminarlo no reduce el valor del desarrollador de Java, pero sí reduce los costos de mantenimiento a largo plazo del JDK.
Conclusión
Java 15 continúa su ciclo de lanzamiento de seis meses y es un lanzamiento de tamaño medio útil para la mayoría de los desarrolladores.