JDK 15: las nuevas funciones de Java 15

Java Development Kit 15, la implementación de Oracle de la próxima versión de Java SE (Standard Edition), está disponible como versión de producción hoy, 15 de septiembre de 2020. Los aspectos más destacados de JDK 15 incluyen bloques de texto, clases ocultas, una API de acceso a memoria externa, el recolector de basura Z y vistas previas de clases selladas, coincidencia de patrones y registros.

JDK 15 es solo una versión a corto plazo, solo para ser compatible con Oracle Premier Support durante seis meses hasta que llegue JDK 16 el próximo marzo. JDK 17, la próxima versión de soporte a largo plazo, que será compatible con Oracle durante ocho años, está programada para llegar dentro de un año, según la cadencia de lanzamiento de seis meses de Oracle para las versiones de Java SE.

Los desarrolladores pueden mirar JDK 15 ahora para tener una idea de lo que habrá en JDK 17, dijo Georges Saab, presidente de Java Platform Group de Oracle. La versión actual de LTS es JDK 11, que llegó en septiembre de 2018. Las versiones de LTS llegan cada tres años. JDK 15 sigue a JDK 14, que se lanzó el 17 de marzo de 2020. 

Las nuevas características y cambios en OpenJDK 15:

  • Una segunda incubadora de una API de acceso a memoria externa, que permitiría a los programas Java acceder de manera segura y eficiente a la memoria externa fuera del montón de Java. La API debería poder operar en varios tipos de memoria externa, como el montón nativo, persistente y administrado. Muchos programas Java acceden a la memoria externa, como Ignite y MapDB. La API ayudaría a evitar el costo y la imprevisibilidad asociados con la recolección de basura, compartir la memoria entre procesos y serializar y deserializar el contenido de la memoria al mapear archivos en la memoria. Actualmente, la API de Java no proporciona una solución satisfactoria para acceder a la memoria externa. Pero con la nueva propuesta, no debería ser posible que la API socave la seguridad de la JVM. Esta capacidad está pasando por una fase de incubadora anterior en JDK 14, con mejoras ofrecidas en JDK 15. 
  • Una vista previa de las clases selladas. Junto con las interfaces, las clases selladas restringen qué otras clases o interfaces pueden extenderlas o implementarlas. Los objetivos de esta característica incluyen permitir que el autor de una clase o interfaz controle qué código es responsable de implementarlo, proporcionar una forma más declarativa que los modificadores de acceso para restringir el uso de una superclase y respaldar las direcciones futuras en la coincidencia de patrones al respaldar la exhaustiva análisis de patrones.
  • Eliminación del código fuente y soporte de compilación para puertos Solaris / SPARC, Solaris / x64 y Linux / SPARC, que se desaprobaron para su eliminación en JDK 14 con la intención de eliminarlos en una versión futura. Muchos proyectos y funciones en desarrollo, como Valhalla, Loom y Panamá, requieren cambios significativos en la arquitectura de la CPU y el código específico del sistema operativo. Dejar de admitir los puertos Solaris y SPARC permitirá a los colaboradores de la comunidad OpenJDK acelerar el desarrollo de nuevas funciones que harán avanzar la plataforma. Tanto Solaris como SPARC han sido reemplazados en los últimos años por el sistema operativo Linux y los procesadores Intel.
  • Los registros, que son clases que actúan como portadores transparentes para datos inmutables, se incluirían en una segunda versión preliminar en JDK 15, después de debutar como una vista previa inicial en JDK 14. Los objetivos del plan incluyen diseñar una construcción orientada a objetos que exprese un agregación simple de valores, lo que ayuda a los programadores a enfocarse en modelar datos inmutables en lugar de comportamiento extensible, implementando automáticamente métodos basados ​​en datos como iguales y evaluadores, y preservando principios de Java de larga data, como tipado nominal y compatibilidad de migración. Los registros se pueden considerar como tuplas nominales. 
  • Firmas criptográficas basadas en el algoritmo de firma digital Edwards-Curve (EdDSA). EdDSA es un esquema de curva elíptica moderno con ventajas sobre los esquemas de firma existentes en el JDK. EdDSA se implementará solo en el proveedor SunEC. EdDSA tiene demanda debido a su seguridad y rendimiento mejorados en comparación con otros esquemas de firmas; ya es compatible con bibliotecas de cifrado como OpenSSL y BoringSSL.
  • Reimplementar la API de DatagramSocket heredada reemplazando las implementaciones subyacentes de las  API java.net.datagram.Sockety java.net.MulticastSocketcon implementaciones más simples y modernas que 1. son fáciles de depurar y mantener y 2. funcionan con subprocesos virtuales que se están explorando actualmente en Project Loom. El nuevo plan es un seguimiento de la propuesta de mejora 353 de JDK que volvió a implementar la API de socket heredada. Las implementaciones actuales java.net.datagram.Sockety java.net.MulticastSocketse remontan a JDK 1.0 y una época en la que IPv6 aún estaba en desarrollo. Por lo tanto, la implementación actual de  MulticastSocket intenta reconciliar IPv4 e IPv6 en formas que son difíciles de mantener.
  • Deshabilitar el bloqueo sesgado de forma predeterminada y desaprobar todas las opciones de línea de comandos relacionadas. El objetivo es determinar la necesidad de un soporte continuo de la optimización de sincronización heredada costosa de mantener del bloqueo sesgado, que se utiliza en la máquina virtual HotSpot para reducir la sobrecarga del bloqueo no atendido. Aunque algunas aplicaciones Java pueden experimentar una regresión en el rendimiento con el bloqueo sesgado desactivado, las ganancias de rendimiento del bloqueo sesgado son generalmente menos evidentes de lo que solían ser.
  • Una segunda vista previa de la coincidencia de patrones para instanceof, después de una vista previa previa en JDK 14. La coincidencia de patrones permite que la lógica común en un programa, principalmente la extracción condicional de componentes de objetos, se exprese de manera más fácil y concisa. Los lenguajes como Haskell y C # han adoptado la coincidencia de patrones por su brevedad y seguridad.
  • Las clases ocultas, es decir, las clases que no pueden ser utilizadas directamente por el código de bytes de otras clases, están diseñadas para ser utilizadas por marcos que generan clases en tiempo de ejecución y que las utilizan indirectamente a través de la reflexión. Una clase oculta se puede definir como miembro de un nido de control de acceso y se puede descargar independientemente de otras clases. La propuesta mejoraría la eficiencia de todos los lenguajes en la JVM al permitir que una API estándar defina clases ocultas que no son detectables y tienen un ciclo de vida limitado. Los marcos dentro y fuera del JDK podrían generar clases dinámicamente que en su lugar podrían definir clases ocultas. Muchos lenguajes creados en JVM se basan en la generación de clases dinámicas para obtener flexibilidad y eficiencia. Los objetivos de esta propuesta incluyen: permitir que los marcos definan clases como detalles de implementación no detectables del marco,por lo que no pueden ser vinculados por otras clases ni descubiertos mediante la reflexión; soporte para ampliar un nido de control de acceso con clases no detectables; y soporte para la descarga agresiva de clases no detectables, por lo que los marcos tienen la flexibilidad de definir tantas como sea necesario. Otro objetivo es dejar de lado la API no estándar, misc.Unsafe::defineAnonymousClass, con la intención de desaprobar su eliminación en una versión futura. Además, el lenguaje Java no se cambiará como resultado de esta propuesta.
  • El recolector de basura Z (ZGC) pasa de una función experimental a un producto de esta propuesta. Integrado en JDK 11, que llegó en septiembre de 2018, ZGC es un recolector de basura escalable y de baja latencia. ZGC se introdujo como una capacidad experimental porque los desarrolladores de Java decidieron que una característica de este tamaño y complejidad debería incorporarse con cuidado y de forma gradual. Desde entonces, se han agregado una serie de mejoras, que van desde la descarga de clases simultáneas, la eliminación de la memoria no utilizada y la compatibilidad con el intercambio de datos de clases hasta una mejor conciencia de NUMA y el pre-toque de montón de subprocesos múltiples. Además, el tamaño máximo del montón se ha aumentado de cuatro terabytes a 16 terabytes. ZGC aborda los problemas de rendimiento en aplicaciones que involucran cantidades masivas de datos, como el aprendizaje automático,donde los usuarios quieren estar seguros de que el procesamiento de datos no estará sujeto a imprevisibilidad o largas pausas debido a la recolección de basura. Las plataformas compatibles incluyen Linux, Windows y MacOS.
  • Los bloques de texto, previsualizados tanto en JDK 14 como en JDK 13, están destinados a simplificar la tarea de escribir programas Java al facilitar la expresión de cadenas que abarcan varias líneas de código fuente, evitando las secuencias de escape en casos comunes. 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 manera predecible y ofrece al desarrollador control sobre el formato cuando lo desee. Un objetivo de la propuesta de bloques de texto es mejorar la legibilidad de cadenas en programas Java que denotan código escrito en lenguajes que no son Java. Otro objetivo es admitir la migración de literales de cadena estipulando que cualquier construcción nueva puede expresar el mismo conjunto de cadenas que un literal de cadena, interpretar las mismas secuencias de escape y manipularse de la misma manera que un literal de cadena.Los desarrolladores de OpenJDK esperan agregar secuencias de escape para administrar espacios en blanco explícitos y control de nueva línea.
  • El recolector de basura Shenandoah de bajo tiempo de pausa se convertiría en una característica de producción y saldría de la etapa experimental. Se había integrado en JDK 12 hace un año.
  • Eliminación de Nashorn, que debutó en JDK 8 en marzo de 2014, pero que desde entonces ha quedado obsoleto por tecnologías como GraalVM. La propuesta de OpenJDK 15 exige la eliminación de las API de Nashorn y la herramienta de línea de comandos jjs que se usa para invocar a Nashorn.
  • Desactivación del mecanismo de activación de RMI, para su eliminación futura. El mecanismo de activación de RMI es una parte obsoleta de RMI que ha sido opcional desde Java 8. La activación de RMI impone una carga de mantenimiento constante. Ninguna otra parte de RMI quedará obsoleta.