¿Qué hay de nuevo en Java 17 y Java 11?

La versión de soporte a largo plazo (LTS) del lenguaje Java y la plataforma de tiempo de ejecución Java 17 se introdujo el 14 de septiembre de 2021. Veamos qué hay de nuevo en Java 17 y si debe actualizar.

Muchas aplicaciones utilizan versiones anteriores de Java, incluidas las versiones LTS anteriores de Java: Java 11 y Java 8.

¿Por qué las empresas deberían actualizarse a la última versión de Java? La actualización a Java 17 requiere esfuerzo, especialmente para utilizar de manera óptima las nuevas características y funciones dentro de la JVM.

Muchas empresas utilizan imágenes de Docker y Docker para migrar fácilmente a Java 17 con un mínimo de esfuerzo y tiempo. Los desarrolladores pueden definir sus pipelines de integración / implementación continua (CI / CD) y ejecutar todo en imágenes de Docker. Esto no afecta a otros equipos que usan versiones anteriores de Java, ya que pueden usar imágenes antiguas de Docker.

Funciones de JAVA 17

Compatibilidad con macOS y AArch64

Una de las características críticas de JVM agregadas a esta versión es la mejora en el soporte para macOS en la arquitectura AArch64 con JEP 391. Soportará la última línea de procesadores (M1) que Apple lanzó con sus computadoras el año pasado.

Esto no es necesariamente un gran problema para los usuarios de estas plataformas, ya que algunos proveedores han lanzado versiones de JDK que admiten esta arquitectura e incluso devuelven compatibilidad con Java 8. Sin embargo, el sello oficial de aprobación es fundamental para el futuro mantenimiento y soporte de la Plataforma. En comparación, se ha agregado soporte para la plataforma Linux / AArch64 a Java 9 y Windows / AArch64 a Java 16.

Clases selladas

Las clases selladas es una función que se introdujo en Java 17. La función Sealed Classes ha finalizado su fase de prueba y se ha convertido en una plataforma y un lenguaje oficiales en Java 17. Permite a un desarrollador especificar los subtipos permitidos que puede tener un tipo y evitar que otros lo expandan o lo implementen de manera no intencionada.

Las clases selladas también permiten que el compilador genere errores en tiempo de compilación si intenta convertir un tipo no sellado en un subtipo ilegal. Java 17 también trae una nueva canalización de renderizado para aplicaciones AWT / Swing que se ejecutan en macOS y usan la API de Apple Metal en lugar de OpenGL. Tiene una API mejorada y una funcionalidad ampliada para generar números aleatorios.

Cambios, eliminaciones y restricciones en Java 17

Java 17 también trae varios cambios, eliminaciones y nuevas restricciones.

Encapsulación de componentes internos de JDK

Un cambio es la finalización del proceso de encapsulación de JDK Internals. Esto se introdujo por primera vez en Java 9 y emitía advertencias en tiempo de ejecución si un usuario intentaba usar Reflection o algo similar para evitar las restricciones habituales sobre el uso de API internas. También se han agregado argumentos de línea de comando para regular este comportamiento.

A partir de Java 9, se crearon varias API para proporcionar una forma unificada de realizar las tareas más utilizadas; Los usuarios utilizarían estas API internamente. Con Java 16, la configuración predeterminada se cambió de una advertencia a deshabilitar el acceso para lanzar una excepción. Sin embargo, usa el argumento de la línea de comando para cambiar el comportamiento.

Con Java 17 se omite el argumento de la línea de comandos y es posible desactivar esta restricción. Esto significa que todo acceso no autorizado a estas API internas ahora está protegido.

Semántica de coma flotante siempre estricta

Otra «eliminación» puede describirse como la reintroducción de una semántica de punto flotante siempre estricta. Java 1.2 introdujo cambios en la semántica de coma flotante predeterminada en Java que permiten a la JVM intercambiar precisión minuciosa en cálculos de coma flotante para mejorar el rendimiento. En clases y métodos donde se tuvo que usar semántica estricta, entre otros strictfp Se agregó la palabra clave. Desde entonces, se han introducido varios tipos de conjuntos de instrucciones en las CPU, lo que permite utilizar una semántica de coma flotante estricta sin costes innecesarios. Se ha eliminado la necesidad de implementar semántica estándar o estricta.

Java 17 elimina la semántica estándar anterior y todas las operaciones de punto flotante se llevan a cabo estrictamente. El término strictfpaún está disponible. Sin embargo, no tiene ningún efecto y produce una advertencia en tiempo de compilación.

Compilación Ahead-of-Time (AOT)

Java 9 introdujo la compilación AOT (Ahead-of-Time) como una función experimental utilizando el compilador Graal, y el código JIT se escribió utilizando Java. Java 10 hizo que el compilador Graal se pudiera usar al integrar la interfaz JVMCI como un compilador JIT en OpenJDK. Ha habido una gran mejora desde su lanzamiento. El compilador de Graal ha logrado un progreso tremendo y tiene su JVM llamada GraalVM.

Activación RMI

La activación de RMI se eliminó en JEP 407 después de la eliminación de Java 8 y finalmente se marcó como obsoleta y se marcó como un requisito previo para la eliminación en Java 15. La activación de RMI proporcionó un método para activar recursos distribuidos de Object On Demand mediante RMI. Sin embargo, se ha utilizado mínimamente y en la actualidad existe una alternativa mejor. El resto del RMI no se ve afectado por la eliminación de la parte de Activación.

Eliminando la API del subprograma

La API del subprograma finalmente fue designada para su eliminación por JEP 398, originalmente eliminada en Java 9. La API del subprograma proporcionó una forma de integrar los controles Java AWT / Swing en una página web dentro de un navegador. Sin embargo, ningún navegador moderno puede admitir esto, lo que significa que los applets han sido esencialmente inaccesibles durante la última década.

Gerente de seguridad

La configuración más importante es el administrador de seguridad (JEP 411). Security Manager existe desde hace un tiempo desde Java 1.0. Está diseñado para restringir lo que Java puede hacer localmente en la computadora, como restringir el acceso a redes, archivos y otros recursos de la red. También intenta proteger el código en el que no se puede confiar bloqueando la reflexión y ciertas API.

El final de Security Manager comenzó en Java 12. Se agregó un argumento de línea de comando para bloquear el uso de Security Manager en tiempo de ejecución. El cambio realizado en Java 17 significa que se genera una advertencia de tiempo de ejecución en la JVM cuando se intenta establecer un administrador de seguridad, ya sea desde la línea de comandos o dinámicamente en tiempo de ejecución.

Funciones de incubadora y vista previa

Muchos se preguntaron si Java 17 tendría capacidades de vista previa e incubadora, considerando que Java 17 se anunciaba como una versión compatible a largo plazo. ¡Java 17 tiene dos módulos de incubadora y una función de vista previa!

API de vector

Vector API (JEP 414) se encuentra actualmente en la segunda fase de la incubadora. La API permite a los desarrolladores definir cálculos vectoriales, que el compilador JIT luego convierte en las instrucciones vectoriales adecuadas admitidas por la arquitectura de la CPU en la que se ejecuta la JVM (por ejemplo, las de los conjuntos de instrucciones SSE o AVX).

Anteriormente, los desarrolladores tenían que usar funciones escalares o crear bibliotecas nativas específicas para la plataforma. La implementación de la API de Vector en Java también proporciona un mecanismo de respaldo perfecto que era complicado en versiones anteriores.

La estandarización de la API Vector permite que las clases dentro del JDK la utilicen. Los métodos de desajuste () de las matrices de Java podrían modificarse para ejecutarse en Java, eliminando la necesidad de mantener y escribir múltiples implementaciones específicas de la plataforma dentro de la JVM.

API de almacenamiento y función externa

Una función adicional de la incubadora se denomina API de memoria y función ajena (JEP 412). Es un desarrollo posterior y una fusión de otros dos módulos de incubadora de Java 16, a saber, la API de enlace externo (JEP 389) y la API de memoria externa (JEP 393). Ambos proporcionan acceso a la memoria nativa y al código utilizando programación de tipo estático escrito en Java.

Coincidencia de patrones para interruptores

La característica final de la vista previa del idioma incluida en Java 17 es la inclusión de Pattern Matching para Switch (JEP 406). Esta función de lenguaje amplía las expresiones y declaraciones de cambio por tipo, similar a la sintaxis utilizada en Pattern Matching (JEP 394), que se convirtió en estándar con Java 16.

En el pasado, si deseaba realizar varias acciones basadas en la naturaleza dinámica de un objeto, tenía que crear una cadena if-else con una instancia de comprobaciones, como:

String type(Object o) { if (o instanceof List) { return "A List of things."; } else if (o instanceof Map) { return "A Map! It has keys and values."; } else if (o instanceof String) { return "This is a string."; } else { return "This is something else."; }}

Combinando la expresión del conmutador y la nueva función de coincidencia de patrones para conmutadores, el proceso se puede reducir a lo siguiente:

String type(Object o) { return switch (o) { case List l -> "A List of things."; case Map m -> "A Map! It has keys and values."; case String s -> "This is a string."; default -> "This is something else."; };}

Como habrás notado, se está declarando una variable. Al igual que con las otras variables en Pattern, la coincidencia de instancias indica que este objeto ha sido verificado y emitido por tipo y está disponible en la variable en su ámbito actual.

La función de vista previa es un paso más en la dirección de la comparación de patrones. El siguiente paso es incluir la capacidad de deconstruir matrices y registros.

¿Debería actualizar a Java 17?

Sí, debe seguir actualizándose a la última versión, pero no el primer día. Es posible que el software y las bibliotecas que está utilizando no se hayan actualizado para que sean compatibles con Java 17, por lo que es posible que deba esperar un tiempo para que esto se complete.

Si se queda atascado con una versión LTS de Java como Java 8 o Java 11, existen numerosas opciones dentro del lenguaje y dentro de la propia JVM que requieren actualizar a Java 17. Dado que se trata de una versión de mantenimiento a largo plazo, existe una alta posibilidad de que su entorno de producción también se actualice a Java 17 en algún momento.

Si está comenzando un proyecto completamente nuevo, o está en el proceso de preparar su proyecto para Java 17, probablemente será más eficiente pasar a Java 17 tarde o temprano, ya que reducirá los costos de mudanza. Esto permite a los desarrolladores que trabajan en el proyecto aprovechar también las últimas funciones y la página de operaciones.

Puede beneficiarse de las muchas mejoras que se han realizado en los últimos años, como: