Oracle anuncia el lanzamiento de Java 17, la última versión del lenguaje de programación y la plataforma de desarrollo número uno del mundo. Java 17 ofrece miles de actualizaciones de rendimiento, estabilidad y seguridad, así como 14 JEP (Propuestas de Mejora del JDK) que mejoran aún más el lenguaje y la plataforma Java para ayudar a los desarrolladores a ser más productivos.
Java 17 es la última versión con soporte de larga duración (long-term support – LTS) en el marco de la cadencia de lanzamiento semestral de Java, y es el resultado de una amplia colaboración entre los ingenieros de Oracle y otros miembros de la comunidad mundial de desarrolladores de Java a través del OpenJDK Community y el Java Community Process (JCP). Desde el anterior JDK 11 LTS, publicado hace tres años, se han implementado más de 70 JEPs.
Ofrecer una licencia más sencilla
Oracle JDK 17 y las futuras versiones de JDK se ofrecen bajo una licencia de uso gratuito hasta un año después de la siguiente versión LTS. Oracle también seguirá proporcionando las versiones de Oracle OpenJDK bajo licencia GPL de código abierto, como lo ha hecho desde 2017.
Mejorar el apoyo a largo plazo a los clientes
Oracle está colaborando con la comunidad de desarrolladores de Java y el JCP en la mejora de la calendarización de las LTS para dar a las organizaciones más flexibilidad sobre cuándo migrar a una versión LTS de Java más reciente. Oracle ha propuesto que la próxima versión LTS sea Java 21 y esté disponible en septiembre de 2023, lo que cambiará la cadencia actual de las versiones LTS de tres a dos años.
Con Oracle LTS y Java SE Subscription, los clientes pueden migrar a Java 17 al ritmo que mejor se adapte a sus necesidades. Oracle proporcionará a los clientes actualizaciones de seguridad, rendimiento y corrección de errores para Java 17 hasta al menos septiembre de 2029.
“En los últimos tres años hemos escuchado lo mucho que les gustan a los desarrolladores las últimas funcionalidades, y hemos visto como el ecosistema adoptaba la cadencia de lanzamientos de seis meses», afirma Georges Saab, vice president of development, Java Platform Group, Oracle. «Uno de los mayores retos a los que se enfrentan los desarrolladores de Java hoy en día es que sus organizaciones sólo les permiten utilizar la última versión LTS. Ahora, con versiones LTS cada dos años, los desarrolladores que trabajan en organizaciones más conservadoras tendrán más opciones y acceso a las funciones que les gustan y quieren utilizar”.
Acelerar la adopción de Java en la nube
Java es una de las plataformas de desarrollo más exitosas de la historia y se basa en una innovación continua que responde a las necesidades cambiantes de los desarrolladores. Para acelerar la adopción de Java en la nube, Oracle ha presentado recientemente Oracle Java Management Service, un nuevo servicio nativo de Oracle Cloud Infrastructure (OCI) para ayudar a las organizaciones a gestionar runtimes y aplicaciones Java on-premises o en cualquier nube.
Java Management Service ofrece a los clientes visibilidad de sus implantaciones de Java en toda la empresa, lo que abarca las distintas versiones de Java instaladas en todo su entorno, incluidas las que se ejecutan en desarrollo y en producción. También indica cualquier aplicación Java no planificada que se esté ejecutando, y comprueba si todas las versiones de Java instaladas están actualizadas con los últimos parches de seguridad.
JDK 17 incluye nuevas mejoras del lenguaje, actualizaciones de las bibliotecas, soporte para nuevos ordenadores Apple, eliminación y supresión de funciones heredadas, y trabaja para garantizar que el código Java escrito hoy siga funcionando sin cambios en futuras versiones del JDK. También ofrece una vista previa de las características del lenguaje y la incubación de APIs para recoger comentarios de la comunidad Java. Las actualizaciones incluyen:
Mejoras del lenguaje Java
- JEP 409: Sealed Classes: las clases e interfaces selladas restringen qué otras clases o interfaces pueden extenderlas o implementarlas. Esta mejora es una más de las de Project Amber, cuyo objetivo es aumentar la productividad de los desarrolladores mediante la evolución del lenguaje Java.
Actualizaciones y mejoras en las bibliotecas
- JEP 306: la vuelta de Always-Strict Floating-Point Semantics: el lenguaje de programación Java y la máquina virtual Java originalmente sólo tenían “semántica estricta de punto flotante”. A partir de Java 1.2 se permitieron por defecto pequeñas variaciones en esa semántica estricta para acomodar las limitaciones de las arquitecturas de hardware existentes. Esas variaciones ya no son útiles o necesarias, por lo que han sido eliminadas por JEP 306.
- JEP 356: Generador de números pseudoaleatorios mejorado: proporciona nuevos tipos de interfaz e implementaciones para los generadores de números pseudoaleatorios (PRNG). Este cambio mejora la interoperabilidad de diferentes PRNG y facilita la solicitud de un algoritmo basado en los requisitos, en lugar de codificar una implementación específica.
- JEP 382: nuevo Rendering Pipeline de macOS: implementa un pipeline Java 2D para macOS utilizando la API Metal de Apple. El nuevo pipeline reducirá la dependencia de JDK de la obsoleta API OpenGL de Apple.
Soporte de la Nueva Plataforma
- JEP 391: macOS AArch64 Port: adapta el JDK a la plataforma macOS/Arch64. Este port permitirá que las aplicaciones Java se ejecuten de forma nativa en los nuevos Apple Silicon basados en Arm 64.
Retiradas y Eliminaciones
- JEP 398: Eliminar la API de Applet para suprimirla: todos los proveedores de navegadores web han eliminado la compatibilidad con los complementos de navegador de Java o han anunciado que tienen previsto hacerlo. La API de Applet quedó obsoleta en Java 9 en septiembre de 2017, pero no para su eliminación.
- JEP 407: Eliminar la activación RMI: elimina el mecanismo de Activación RMI, pero conserva el resto de RMI.
- JEP 410: Eliminar los compiladores experimentales AOT y JIT: los compiladores experimentales ahead-of-time (AOT) y just-in-time (JIT) basados en Java fueron características experimentales que no han sido muy adoptadas. Al ser opcionales, ya se eliminaron del JDK 16. Este JEP elimina estos componentes del código fuente de JDK.
- JEP 411: Desaparición del Gestor de Seguridad para su eliminación: Security Manager se remonta a Java 1.0. No ha sido el medio principal para asegurar el código Java del lado del cliente durante muchos años, y rara vez se ha utilizado para asegurar el código del lado del servidor. Su desaparición en una futura versión eliminará una importante carga de mantenimiento y permitirá a la plataforma Java avanzar.
Programas Java de cara al futuro
- JEP 403: Encapsular fuertemente los elementos internos de JDK: ya no será posible relajar el encapsulamiento fuerte de los elementos internos mediante una sencilla opción de línea de comandos, como sí lo era en JDK 9 y hasta JDK 16. Seguirá siendo posible acceder a las API internas existentes, pero ahora será necesario enumerar, como parámetros de la línea de comandos o atributos manifiestos de archivo JAR, cada uno de los paquetes cuya encapsulación debería ser relajada. Este cambio dará lugar a aplicaciones más seguras y a menos dependencias de detalles de implementación internos no estándar de JDK.
Previsualizaciones e incubadoras para posteriores versiones del JDK
- JEP 406: Coincidencia de Patrones (Vista Previa): permite probar una expresión contra varios patrones, cada uno de ellos con una acción específica, de modo que las consultas complejas orientadas a datos pueden expresarse de forma concisa y segura.
- JEP 412: Foreign Function y memoria API (Incubadora): mejora las APIs de incubación introducidas en JDK 14 y JDK 15 que permiten a los programas Java interoperar con código y datos fuera de Java runtime. Mediante la invocación eficiente de funciones ajenas (por ejemplo, código fuera de la JVM) y el acceso seguro a memoria ajena, estas APIs permiten a los programas Java llamar a bibliotecas nativas y procesar datos nativos sin la fragilidad y la complejidad de Java Native Interface (JNI). Estas APIs se están desarrollando en Project Panama, cuyo objetivo es mejorar la interacción entre el código Java y el que no lo es.
- JEP 414: Vector API (Segunda Incubadora): permite expresar cálculos vectoriales que se compilan de forma fiable en runtime con instrucciones vectoriales optimizadas en las arquitecturas de CPU compatibles, consiguiendo así un rendimiento superior al de los cálculos escalares equivalentes.
