Java JDK 11: todas las funciones nuevas ahora disponibles

Java Development Kit (JDK) 11 ahora está disponible de forma general y está listo para su uso en producción, lo que aporta mejoras de productividad y una API de cliente HTTP que implementa HTTP / 2.

La versión 11 de Java Standard Edition (SE) tiene 16 cambios importantes en las funciones. Java 11 también pierde algunas capacidades debido a la eliminación de los módulos CORBA y Java EE (recientemente renombrado como Jakarta EE), así como la eliminación de JavaFX, que ahora está disponible como tecnología independiente.

En Java 11, Oracle ha bifurcado el repositorio principal, jdk / jdk, al repositorio de estabilización jdk / jdk11. Los cambios enviados a jdk / jdk o jdk / client ahora están marcados para JDK 12. El repositorio de estabilización puede aceptar correcciones de errores seleccionadas y, si se aprueban, mejoras tardías según el proceso de lanzamiento de JDK.

La última versión de la implementación de Java estándar de Oracle es una versión de soporte a largo plazo (LTS), que contará con el soporte comercial de Oracle durante al menos ocho años. Se ofrecerán correcciones de errores y actualizaciones de seguridad hasta el 2026. Los nuevos lanzamientos de LTS vencen cada tres años, y el JDK 17, que vence en 2021, será el próximo lanzamiento de LTS. Los comunicados provisionales se producirán cada seis meses.

Dónde descargar JDK 11

Puede descargar JDK 11 desde Oracle Technology Network.

Nuevas funciones en Java 11 JDK

JDK 11 tiene 16 características nuevas:

  • Mejora de los intrínsecos de Aarch64, con la implementación de nuevos intrínsecos para las  lang.Mathfunciones sin, cos y log, en los procesadores Aarch64. Esta propuesta enfatiza los patrones de código específicos de la arquitectura de CPU especializados que mejoran el rendimiento de la aplicación y la evaluación comparativa.
  • El control de acceso basado en nidos introduce nidos, un contexto de control de acceso que se alinea con la noción de tipos anidados en el lenguaje Java. Los nidos permiten clases que son lógicamente parte de la misma entidad de código pero que se compilan en archivos de clases distintos para acceder a los miembros privados de cada uno sin necesidad de compiladores para insertar métodos de puente de ampliación de accesibilidad.
  • Transport Layer Security (TLS) 1.3, en el que esta revisión del protocolo TLS se incluirá en JDK 11, ofreciendo importantes beneficios de seguridad y rendimiento. Sin embargo, no existe ningún objetivo para admitir todas las funciones de TLS 1.3. Para minimizar los riesgos de incompatibilidad, TLS 1.3 implementará el modo de compatibilidad con versiones anteriores de forma predeterminada. Las aplicaciones pueden activar o desactivar este modo según se desee.
  • Desactivación del motor de JavaScript Nashorn, junto con la herramienta JJS, con la intención de eliminarlos en el futuro. Para Oracle, Nashorn ha encontrado un desafío de mantener, dado el rápido ritmo al que se han adaptado y modificado las construcciones y API del lenguaje ECMAScript.
  • Cliente HTTP (estándar), que estandariza el cliente API HTTP incubado introducido en JDK 9 y actualizado en JDK 10. La API ofrece semántica de respuesta y solicitud sin bloqueo CompleteableFutures, que puede vincularse para desencadenar acciones dependientes. La implementación, ahora asincrónica, se ha reescrito casi por completo, después de incubar en los JDK 9 y 10. El concepto RX Flow se ha introducido en la implementación, eliminando muchos conceptos personalizados necesarios para admitir HTTP / 2. El flujo de datos ahora se puede rastrear más fácilmente, desde los publicadores de solicitudes a nivel de usuario y los publicadores de respuestas hasta el socket subyacente. Esto reduce la complejidad y maximiza la posibilidad de reutilización entre HTTP / 1 y HTTP / 2.
  • El recolector de basura Epsilon, catalogado como un recolector "sin operación", manejará la asignación de memoria sin implementar ningún mecanismo real de recuperación de memoria. Los casos de uso de Epsilon incluyen pruebas de rendimiento, presión de memoria y la interfaz de la máquina virtual. También podría utilizarse para trabajos de corta duración.
  • Una sintaxis de variable local para parámetros lambda debe alinear la sintaxis de una declaración de parámetro formal en una expresión escrita implícitamente con la sintaxis de una declaración de variable local. Esto permitiría var su uso al declarar parámetros formales de expresiones lambda tipadas implícitamente.
  • El formato de la clase-archivo Java se extenderá a apoyar una nueva piscina de forma constante, CONSTANT_Dynamic. El objetivo es reducir el costo y la interrupción del desarrollo de nuevas formas de restricciones materializables en los archivos de clases.
  • El acuerdo clave con la criptografía Curve25519 y Curve448 debería ser más eficiente y seguro que el esquema Diffie-Hellman de curva elíptica existente. Las dos curvas elípticas, Curve25510 y Curve448, se prestan a una implementación de tiempo constante y una multiplicación escalar sin excepciones que es más resistente a una variedad de ataques de canal lateral, incluidos los ataques de tiempo y caché, según el IETF. Los objetivos de la propuesta incluyen una API y la implementación del esquema de acuerdos clave, así como el desarrollo de una implementación totalmente Java independiente de la plataforma. Sin embargo, existe un riesgo en la complejidad y sutileza de la implementación aritmética modular presentada como parte de la propuesta.
  • Flight Recorder proporcionaría un marco de recopilación de datos de bajo costo para la resolución de problemas tanto de aplicaciones Java como de HotSpot JVM. Flight Recorder ha sido una función del JDK comercial de Oracle, pero su código fuente se trasladaría a un repositorio abierto para que la función esté disponible de forma generalizada. Iclouded serían las API para producir y consumir datos como eventos, proporcionando un mecanismo de búfer y formato de datos binarios y permitiendo la configuración y el filtrado de eventos. La propuesta también exige la provisión de eventos para las bibliotecas OS, HotSpot y JDK.
  • Actualización de las API de la plataforma para admitir Unicode Versión 10.0, manteniendo Java actualizado. Se espera apoyo en las siguientes clases:
    • Charactery Stringen el langpaquete
    • NumericShaperen el awt.fontpaquete
    • Bidi, BreakIteratory Normalizeren el textpaquete
  • Implementación de los algoritmos criptográficos ChaCha20 y Poly1305. ChaCha2020 es un cifrado de flujo relativamente nuevo que puede reemplazar el cifrado de flujo R4 más antiguo e inseguro. ChaCha20 se emparejaría con el autenticador Poly1305. Se proporcionarían implementaciones de cifrado ChaCha20 y ChaCha20-Poly1305, con los algoritmos implementados en el proveedor SunJCE (Java Cryptography Extension), utilizando la crypto.CipherSpiAPI.
  • Mejora del lanzador de Java para ejecutar un programa proporcionado como un solo archivo de código fuente de Java, de modo que estos programas puedan ejecutarse directamente desde la fuente. Los programas de un solo archivo son comunes cuando se escriben pequeñas utilidades o para desarrolladores en las primeras etapas de aprendizaje de Java. Además, un solo archivo de origen puede compilarse en varios archivos de clase, lo que agrega una sobrecarga de empaquetado. En estos contextos, tener que compilar un programa antes de ejecutarlo es solo un paso innecesario basado en la tradición.
  • Generación de perfiles de montón de baja sobrecarga, que proporciona una forma de muestrear asignaciones de montón de Java, accesible a través de la interfaz de la herramienta JVM. El objetivo de este esfuerzo es obtener información sobre estas asignaciones de una manera que sea de bajo costo, se pueda acceder a ella a través de una interfaz programática y pueda muestrear todas las asignaciones. La independencia de la implementación y el suministro de datos sobre montones vivos y muertos también son objetivos. Una gestión deficiente del montón puede provocar el agotamiento del montón y la eliminación de basura. La mayoría de las herramientas que abordan esto carecen del sitio de llamadas para asignaciones particulares, información que puede ser crítica para depurar problemas de memoria.
  • Desactivación de las herramientas Pack200 y Unpack200 y la API Pack200 en util.jar. Pack200 es un esquema de compresión para archivos .jar, destinado a reducir los requisitos de ancho de banda y disco para el empaquetado, transmisión y entrega de aplicaciones. Los costos de mantenimiento y el bajo uso no justifican su retención, dicen los líderes del proyecto.
  • El recolector de basura Z (ZGC), un recolector de basura experimental de baja latencia, para manejar montones que van desde montones relativamente pequeños a muy grandes que tienen muchos terabytes de tamaño. Al usar ZGC, los tiempos de pausa no deben exceder los 10 ms y no debe haber una reducción del rendimiento de la aplicación de más del 15 por ciento en comparación con el uso del colector G1. ZGC también sienta las bases para futuras funciones y optimizaciones. Linux / x64 será la primera plataforma en obtener soporte para ZGC.

Qué se eliminó de Java JDK 11

Los módulos Java EE EE y CORBA quedaron obsoletos en Java SE 9, con la intención de eliminarlos en una versión posterior, que es JDK 11.

Java SE 6, lanzado en diciembre de 2006, había incluido una pila completa de servicios web para la conveniencia de los desarrolladores, incluidas cuatro tecnologías creadas para la plataforma Java EE: JAX-WS (API Java para servicios web basados ​​en XML, JAXB (Arquitectura Java para XML Binding), JAF (JavaBeans Activation Framework) y Common Annotations for Java. Con el tiempo, las versiones de Java EE evolucionaron, lo que generó dificultades en Java SE, como la inclusión de tecnologías irrelevantes para Java SE y un mantenimiento más difícil en los dos Java Con versiones independientes de las tecnologías Java EE disponibles en sitios de terceros, Oracle dice que ya no es necesario tenerlas en Java SE o en el JDK.

Aún así, algunas aplicaciones no se compilarán ni se ejecutarán si dependen del soporte listo para usar en las herramientas y API de JDK para Java EE. Surgirían incompatibilidades binarias y de origen al migrar JDK 6, 7 u 8 a una versión posterior. Oracle dice que los desarrolladores afectados por estos riesgos pueden implementar versiones alternativas de tecnologías Java EE en su lugar.

CORBA se remonta a la década de 1990 y Oracle dice que hoy en día no existe un interés significativo en desarrollar aplicaciones Java modernas con CORBA. Y los costos de mantener el soporte de CORBA superan los beneficios restantes.

Pero la eliminación de CORBA corre el riesgo de tener implementaciones de CORBA que no se ejecutarán si incluyen solo un subconjunto de API de CORBA y esperan que el JDK proporcione el resto. No existe una versión de CORBA de terceros y no está claro si un tercero podría hacerse cargo del mantenimiento de la API de CORBA.

JavaFX se está eliminando, por lo que no está vinculado al programa de actualización semestral de Java JDK.