La versión Long-Term-Support (LTS) del lenguaje Java y la plataforma de tiempo de ejecución Java 17 se lanzó el 14 de septiembre de 2021. Aprendamos qué hay de nuevo en Java 17 y si debe actualizar.
Muchas aplicaciones usan 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 versión más reciente de Java? La actualización a JAVA17 requiere esfuerzo, principalmente para aprovechar al máximo las nuevas características y funciones dentro de la JVM.
Muchas empresas utilizan Docker y las imágenes de Docker para cambiar fácilmente a Java 17 con el mínimo esfuerzo y tiempo. Los desarrolladores pueden definir sus canalizaciones de integración/implementación continua (CI/CD) y ejecutar todo en imágenes de Docker. Esto no afectará a otros equipos que utilicen versiones anteriores de Java, ya que pueden utilizar imágenes antiguas de Docker.
Tabla de contenido
Características 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 del soporte para macOS en la arquitectura AArch64 usando JEP 391. Admitirá la última serie de procesadores (M1) que Apple lanzó con sus computadoras el año pasado.
No es necesariamente un gran problema para los usuarios de esas plataformas, ya que algunos proveedores han lanzado versiones de JDK que admiten esta arquitectura e incluso brindan soporte desde Java 8. Sin embargo, el sello de aprobación oficial es esencial para garantizar el mantenimiento y soporte futuros de la plataforma. En comparación, se agregó soporte para la plataforma Linux/AArch64 a Java 9 y Windows/AArch64 en Java 16.
Clases selladas
Clases selladas es una función que se introdujo en Java 17. La función Clases selladas ha terminado su fase de prueba y se ha convertido en una plataforma y lenguaje oficial en Java 17. Permite a un desarrollador especificar los subtipos permitidos que puede tener un tipo y evitar que otros la amplíen o la implementen de una forma no prevista.
Las clases selladas también permiten que el compilador genere errores en tiempo de compilación cuando intenta convertir un tipo no sellado en un subtipo no permitido. Java 17 también trae una nueva canalización de renderizado para aplicaciones AWT/Swing que se ejecutan en macOS usando Apple Metal API en lugar de OpenGL. Tiene una API mejorada y características mejoradas para generar números aleatorios.
Cambios, eliminaciones y limitaciones en Java 17
Java 17 también trae varios cambios, eliminaciones y nuevas limitaciones.
Encapsulación de JDK Internals
Un cambio es la conclusión del proceso de encapsulación de JDK Internals. La primera vez que esto se introdujo fue dentro de Java 9 y daría advertencias durante el tiempo de ejecución cuando un usuario intentara usar la reflexión o algo similar para eludir las restricciones habituales sobre el uso de API internas. También se agregaron argumentos de línea de comandos para regular este comportamiento.
A partir de Java 9, se han creado varias API para ofrecer una forma uniforme de realizar las tareas más utilizadas; los usuarios utilizarían estas API internamente. Con Java 16, el valor predeterminado se cambió de una advertencia a deshabilitar el acceso para generar una excepción. Sin embargo, utiliza el argumento de la línea de comandos para modificar el comportamiento.
Con Java 17 se elimina el argumento de la línea de comandos y es posible desactivar esta restricción. Esto significa que todo el acceso no autorizado a esas API internas ahora está protegido.
Semántica de coma flotante siempre estricta
Una «eliminación» adicional se puede describir como la reintroducción de la semántica de coma flotante siempre estricta. Java 1.2 introdujo modificaciones en la semántica predeterminada de punto flotante en Java que permite que la JVM intercambie una pequeña cantidad de precisión en los cálculos de punto flotante para mejorar el rendimiento. En clases y métodos donde se tenía que usar semántica estricta, se agregó una palabra clave strictfp. Desde entonces, se han introducido varios tipos de conjuntos de instrucciones en las CPU, lo que hace que se utilice una semántica estricta de punto flotante sin costos innecesarios. Se ha eliminado la necesidad de implementar una semántica estricta o por defecto.
Java 17 elimina la semántica predeterminada anterior y todas las operaciones de punto flotante se ejecutan estrictamente. El término strictfpis sigue presente. Sin embargo, no tiene ningún efecto y provoca una advertencia en tiempo de compilación.
Compilación anticipada (AOT)
Java 9 introdujo la compilación anticipada (AOT) como una función experimental que utiliza el compilador Graal, y se escribió un código JIT usando Java. Java 10 hizo que el compilador Graal se pudiera usar como un compilador JIT en OpenJDK al incorporar la interfaz JVMCI. Desde su lanzamiento, ha habido una gran mejora. El compilador Graal ha visto grandes avances y tiene su JVM bajo el nombre de GraalVM.
Activación RMI
La activación de RMI se eliminó en JP 407 luego de su eliminación de Java 8 y finalmente quedó en desuso y se marcó como un requisito para la eliminación dentro de Java 15. La activación de RMI proporcionó un método para habilitar recursos a pedido de objetos distribuidos mediante RMI. Sin embargo, vio un uso mínimo, y una mejor alternativa está disponible en el presente. El resto de RMI no se ve afectado por la eliminación de la parte de Activación.
Eliminación de la API del subprograma
Applet API finalmente ha sido designado para su eliminación por 398 JPY, inicialmente eliminado en Java 9. La API Applet 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 subprogramas han sido esencialmente inaccesibles durante la última década más o menos.
Gerente de seguridad
La desaprobación más importante es el administrador de seguridad ( JP 411). Security Manager ha estado en uso durante un tiempo desde Java 1.0. Fue diseñado para restringir lo que Java podía hacer localmente en la máquina, como limitar el acceso a redes, archivos y otros recursos de red. También intenta aislar el código en el que no se confía bloqueando la reflexión y las API específicas.
El final de Security Manager comenzó en Java 12. Se agregó un argumento de línea de comandos para bloquear el uso del administrador de seguridad en tiempo de ejecución. El cambio realizado en Java 17 significa que se generará una advertencia de tiempo de ejecución en la JVM cuando se intente configurar 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 características de vista previa e incubadora, considerando que Java 17 se promocionó para ser una versión con soporte a largo plazo. ¡Java 17 tiene dos módulos de incubadora y una función de vista previa!
API de vectores
API de vectores ( JP 414) se encuentra actualmente en su segunda fase de la incubadora. La API permite a los desarrolladores definir el cómputo vectorial que el compilador JIT luego convertirá en la instrucción vectorial adecuada compatible con la arquitectura de la CPU en la que se ejecuta la JVM (por ejemplo, utilizando los conjuntos de instrucciones SSE o AVX).
Antes, los desarrolladores tenían que usar funciones escalares o crear bibliotecas nativas específicas para la plataforma. La implementación de Vector API en Java también proporciona un mecanismo de respaldo continuo que era complicado en versiones anteriores.
La estandarización de Vector API permite que las clases dentro de JDK la utilicen. Los métodos de discrepancia de Java Arrays () se pueden cambiar para que se ejecuten en Java, eliminando el requisito de mantener y escribir múltiples implementaciones específicas de plataformas dentro de la JVM.
API de memoria y funciones externas
Una característica adicional de la incubadora se llama Foreign Function & Memory API ( JP 412). Es una evolución y fusión de otros dos módulos de incubadora de Java 16 que es The Foreign Linker API ( JPY 389) y API de memoria externa ( JPY 393). Ambos brindan acceso a la memoria nativa y al código mediante el uso de programación de tipo estático escrita en Java.
Coincidencia de patrones para Switch
La característica final de la vista previa del idioma incluida en Java 17 es la inclusión de Pattern Matching for Switch ( JP 406). Esta función de lenguaje expande las expresiones y sentencias de cambio según el tipo, similar a la sintaxis utilizada a través de la coincidencia de patrones (JPY 394), que se convirtió en estándar con Java 16.
En el pasado, si deseaba realizar diferentes acciones en función de la naturaleza dinámica de un objeto, se le solicitaría que construyera una cadena if-else utilizando 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.";
}
}
Al combinar la expresión de cambio con la nueva característica de coincidencia de patrones para interruptores, el proceso se puede reducir a algo similar a:
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, está la declaración de una variable en el proceso de verificación. Al igual que las otras variables en Patrón, la coincidencia de instancia indica que este objeto fue verificado y convertido y está disponible desde la variable dentro de su área actual.
La función de vista previa es otro paso hacia la coincidencia de patrones. El siguiente paso es incluir la capacidad de deconstruir arreglos y registros.
¿Debería actualizar a Java 17?
Sí, debe actualizar constantemente a la versión más reciente, pero no tan pronto como el primer día. Es posible que el software y las bibliotecas que está utilizando no se hayan actualizado para incluir compatibilidad con Java 17, por lo que es posible que deba esperar un tiempo hasta que esté listo.
Si está 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 una actualización a Java 17. Al ser una versión de mantenimiento a largo plazo, hay una alta probabilidad de que su entorno de producción eventualmente se actualice a Java 17 también.
Si está comenzando un proyecto completamente nuevo, o está en el proceso de preparar su proyecto para Java 17, hacer el cambio a Java 17 más temprano que tarde es probablemente la opción más eficiente, ya que reduce los costos de mudanza. Esto también permite a los desarrolladores que trabajan en el proyecto utilizar todas las funciones más recientes y el lado operativo.
Puede aprovechar las numerosas mejoras que se han producido en los últimos años, como la compatibilidad mejorada con los contenedores que se ejecutan en Java, así como las nuevas implementaciones del recolector de elementos no utilizados de baja latencia.